>>>>> On Wed, 7 Aug 2002 13:49:40 +0100, David Laight <david@l8s.co.uk> said:

>> This means that all programs which assume that va_list can be passed
>> as a value in function argument will fail with gcc-3.x, if we use 
>> gcc __builtin_va_list as va_list.
>> 
>> Is this really OK? Why don't gcc people think this as a problem?

> It can't be OK.
> How do you call vprintf() if you can't pass a va_list to it by value?

Well, I relooked at C standard after I wrote the previous mail,
and found the following description:

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

But there is another problem about declaring va_list as an array.
If va_list is an array, two va_list cannot be assigned each other
(because array cannot be assigned in C language.)

So, programs which assume that va_list can be assigned become
to fail with the gcc-3.x on powerpc and i386.

C9X defines va_copy() macro to solve this problem.
But the macro didn't exist on C8X.
(C8X didn't say that va_list can be assigned, but it didn't explicitly
 say that the assignment is prohibited, either.)

Thus, some programs which worked fine with C8X don't work with gcc-3.x
on powerpc and i386. Perhaps this may be OK, but if this problem can
be avoided, that is more desired.
--
soda