Andrew Dunstan <[EMAIL PROTECTED]> 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, and va_copy.
If access to the varying arguments is desired, the called
function shall declare an object (referred to as ap in this
subclause) having type va_list. The object ap may be passed
as an argument to another function; if that function invokes
the va_arg macro with parameter ap, the value of ap in the
calling function 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 which case 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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
