[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