At 11:07 AM 8/7/2002, Noriyuki Soda wrote:
> > Anyway, SVR4 ABI passes large structures (like va_list) by reference
> > anyways.  So in either case a pointer is going to be passed.
>
>But that doesn't mean passing a value and passing an address of
>the value is ABI compatible. Because the latter modifies local
>variable of caller function.

 From the SVR4 PPC ABI:

A struct, union, or long double, any of which shall be treated as
a pointer to the object, or to a copy of the object where necessary to
enforce call-by-value semantics. Only if the caller can ascertain that the
object is "constant" can it pass a pointer to the object itself.

 From ISO-C-1999 (7.15 #3):

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.

The above clearly dictates that:

         va_start(ap, fmt);
         vfprintf(fmt, ap);
         vfprintf(fmt, ap);
         va_end(ap);

is not legal and absolutely non-portable.  However, inserting another
va_end and va_start between the two vfprintf's results in portable
code.

Since my change does not break conforming programs but only those
programs that *already* had a latent bug, and results in us being
compatible with the SVR4 ABI and the gcc distribution, it seem like
the right change to make.


-- 
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message