[libiberty patch] Fix va_list for PowerPC

Andreas Schwab schwab@suse.de
Sun Apr 21 08:40:00 GMT 2002


Daniel Jacobowitz <drow@mvista.com> writes:

|> On Sat, Apr 20, 2002 at 11:50:19PM +0200, Andreas Schwab wrote:
|> > I think the va_copy should rather replace the call to memcpy in
|> > int_vasprintf (there must also always be a matching va_end in the
|> > same function).  But in any way, va_copy should only be used if
|> > defined, so that it still works with pre-C99 compilers.
|> 
|> va_end should match va_start, not va_copy.  There's no point in ending
|> the copy, is there?

The standard disagrees with you:

7.15.1.3 The va_end macro

[#2] The va_end macro facilitates a normal return from the function whose
variable argument list was referred to by the expansion of the va_start
macro, or the function containing the expansion of the va_copy macro, that
initialized the va_list ap. The va_end macro may modify ap so that it is
no longer usable (without being reinitialized by the va_start or va_copy
macro). If there is no corresponding invocation of the va_start or va_copy
macro, or if the va_end macro is not invoked before the return, the
behavior is undefined.

|> Also, has either of these patches been tested?  I do not believe that
|> you can necessarily pass a va_list* to a function.

Yes, you can, see footnote to 7.15[#3]:

212) 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.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



More information about the Gcc-patches mailing list