Andrew Dunstan <andrew@dunslane.net> writes:
> But I also see that my amd64/FC6 machine does pass these tests with gcc.
Yeah, but the typedef represented by va_list can and probably does vary
between amd64 and ppc64. I haven't an easy way to check, but I wonder
whether it's not an array type on ppc.
I'm of the opinion that ecpg is trying to do something here that's not
portable. The C99 draft I have says
[#3] The type declared is
va_list
which is an object type suitable for holding information needed by the macros va_start, va_arg, va_end,
andva_copy. If access to the varying arguments is desired, the called function shall declare an object
(referredto as ap in this subclause) having type va_list. The object ap may be passed as an argument to
anotherfunction; if that function invokes the va_arg macro with parameter ap, the value of ap in the
callingfunction is indeterminate and shall be passed to the va_end macro prior to any further reference to ap.
(198)
____________________
198 It is permitted to create a pointer to a va_list and pass that pointer to another function, in
whichcase the original function may make further use of the original list after the other function
returns.
The footnote seems to say that what the code is doing is OK ... but
there isn't any such footnote in the Single Unix Spec:
http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
which makes me wonder just how portable it really is.
My recommendation is to get rid of the APREF hack, deal only in
va_list not &va_list, and inline ECPGget_variable into the two
places it's used to avoid the question of passing va_lists around
after they've been modified. The routine's not that big (especially
seeing that only half of it is actually shared by the two callers)
and it's just not worth the notational effort, let alone any portability
risks, to factor it out.
regards, tom lane