Subject: Re: CVS commit: syssrc/sys/arch/powerpc/include
To: Noriyuki Soda <soda@sra.co.jp>
From: David Laight <david@l8s.co.uk>
List: tech-toolchain
Date: 08/07/2002 15:34:10
> 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.
>
> This ("the value of ap in the calling function is indeterminate") may
> be the reason that gcc choosed the implementation.
> (This description exists in both C8X and C9X standard.)
I read that as allowing an implementation where 'ap' is actually
a pointer to a lump of memory allocated by va_start and freed
by va_end. Thus the called function can change the contents of
'ap' without changing its value - thus making it indeterminate [1].
David
[1] or at least implementation dependant, since on some systems
ap will be a pointer into the stack, and on others a pointer to
a (dynamically allocated or on stack hidden) data item that
contains the real info. va_arg() updates 'ap' itself in the
first case and *ap in the second.
So on return from a function the callers 'ap' is 'implementation
defined'.
--
David Laight: david@l8s.co.uk