Re: Standards question: va_list vs. va_list *

[Geoff Keating <geoffk at geoffk dot org>]

Ulrich Weigand <weigand@immd1.informatik.uni-erlangen.de> writes:

> Hello,
> 
> on s390 (like in some other backends) we define va_list to
> be of array type.  From my reading of the standard, this
> is supposed to be legal.  However, we've had reports of a
> peculiar problem caused by this.  Consider this program:
> 
> #include <stdarg.h>
> 
> void func (va_list *app);
> void test (va_list ap)
> {
>   func (&ap);
> }
> 
> Is this program conforming to the standard?  The standard
> says on the one hand that you can pass an object of type
> va_list as argument, and on the other hand that it is legal
> to form an va_list * by taking the address of a va_list object.

This is not quite right.  What the standard actually says, in a
footnote, is that:

212) It is permitted to create a pointer to a va_list and pass that
     pointer to another function, ...

Now, it says you're allowed to do this, but you will note that it
doesn't say _how_ to do it.  In particular, I think it's impossible to
do portably if the va_list was a function parameter.  You can do it if
the va_list is a variable, like this:

  va_list ap;
  va_list *ap_p = &ap;

Of course, you can use va_copy to copy a parameter into another
variable, which has the same effect, since it's impossible for a
strictly conforming program to tell the difference between

int foo(va_list ap) { ... }
and
int foo(va_list ap_p) { va_list ap; va_copy (ap, ap_p); { ... } }

> Combining these two in the form above, however, doesn't
> work if va_list is in fact an array type, as the type of
> the argument ap is implicitly adjusted to pointer type,
> and thus &ap is not in fact of type va_list * ...
> 
> Does this mean it is illegal to define va_list as array 
> type after all?  Or is the program above not conforming?

The above program is not strictly conforming.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>