[Bug c/20951] bogus error passing &va_list to va_list*

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From joseph at codesourcery dot com  2005-04-13 20:42 -------
Subject: Re:  bogus error passing &va_list to va_list*

On Mon, 11 Apr 2005, sebor at roguewave dot com wrote:

> Yes, I read that comment but I still don't see anything in the standard the
> footnote is in conflict with and I don't see it on the WG14 DR list(*). If the
> footnote is bogus and va_list can't be universally implemented to allow programs
> to initialize a va_list* with the address of a va_list function argument,it
> ought to be taken out of the standard. If you are not aware of an issue against
> the C standard I'll be happy to send it to the committee myself.

I see nothing wrong with the footnote.  You can create a pointer to a 
va_list, as the footnote notes.  To do so, you need an object of type 
va_list.  Declaring a function parameter as "va_list va" doesn't declare 
such a object if va_list is an array type; it declares one of type 
"va_list_member *" where va_list is an array 
va_list_member[number_of_elements].  Just because it says you can create a 
pointer doesn't mean you can do so with "&va" if va doesn't have va_list 
type, any more that it means you can do so with "random expression I'd 
like to have va_list * type but which has nothing to do with va_list"; 
they are in exactly the same position.  If your expression has type 
va_list * according to the semantics of the language and is the address of 
a va_list object, you can use it.

(comment#1 in this bug is bogus.  &va isn't &va[0], it's the address of 
the pointer argument rather than the address of an element.  Both of these 
are of course different from the address of the va_list object itself 
which has type va_list * (i.e. va_list_member (*)[number_of_elements]) 
instead of va_list_member ** (which &va has) or va_list_member * (which 
&va[0] has).  comment#8 in bug 14557 is just confused as well; ignore it 
and read comments 10-14 instead.)



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20951