>>>>> On Wed, 07 Aug 2002 17:30:14 -0700,
	Matt Thomas <matt@3am-software.com> said:

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

This paragraph is what I already quoted on my message [1].

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

Yes, I know (see [1]).

And this was the example you claimed (in your message [2]) that your
change will not introduce any difference on NetBSD/powerpc.

In other words, the claim you made in message [2] is wrong.
And your change breaks the above code framgment, and introduces 
(perhaps minor, but certain) ABI difference.
Is this guess right?

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

Yes, certainly this has some sense (as I already said in the end of
the message [1]).
But because it is possible that this change breaks existing working
binaries, we shouldn't blindly introduce this change. 
Rather, we should at least test that most existing programs (including
3rd partys' one) will not become broken by this change.

>>>>> On Wed, 7 Aug 2002 19:02:55 -0700,
	Jason R Thorpe <thorpej@wasabisystems.com> said:

> I agree with your analysis, and support your change.

This changes reminds me the change you made at intorduction of
real vfork(). The introduction of real vfork() shouldn't break
any existing programs unless the programs misuse vfork().
But the reality was even our libc had misused vfork() and you
assigned new system call number for real vfork() not to break
existing programs.

If we follows the existing practice, perhaps we should pay similar
effort not to break existing binaries. But perhaps such programs
may be very fewer and the effort may not be worth doing.

But before making the decision, I think multple people should test 
the change to make sure it does not introduce serious problem on
NetBSD/powerpc architecutre, shouldn't they?

P.S.
I wrote "gcc-3.x introduces similar change to i386 architecutre about
va_list", but this was wrong. The code I looked is for x86-64.
(I missed one "if" statement in the code).

[1] Message-Id: <200208071409.XAA17018@srapc342.sra.co.jp>
[2] Message-Id: <5.1.0.14.2.20020807101820.0ae3deb8@3am-software.com>
--
soda