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