Subject: Re: CVS commit: syssrc/sys/arch/powerpc/include
To: David Laight <firstname.lastname@example.org>
From: Noriyuki Soda <email@example.com>
Date: 08/07/2002 23:09:16
>>>>> On Wed, 7 Aug 2002 13:49:40 +0100, David Laight <firstname.lastname@example.org> 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
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.