Re: must use gcc builtin?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> That's a bug, because it means that compiling the caller with one
>> compiler and the callee with another compiler, will give results
>> that don't work

That alone doesn't make it a bug.  Mixing code compiled by different
compilers is, in general, never guaranteed to work.  When it does work,
it works only because both compilers choose the same (or at least
sufficiently compatible) conventions for argument passing (and a few
other things, often, such as struct layout in memory).

>> Perhaps a va_list_to_sequential_memory() conversion interface could
>> be provided.
> Thanks, that is an interesting idea.  It wouldn't be hard, and it
> would permit compilation of the code I pointed to.

It also is not, in general, possible without having the types of all
actual arguments (or at least their default-promoted types) available
at va_list_to_sequential_memory() call time.

For example, on some architectures there may be no difference at all in
argument-passing machine state at point-of-call between the two calls

void foo(int, ...);
foo(1, 7, "foo");
foo(1, "foo", 7);

Using the 68k as an example, I could see this being implemented as
d0=1, d1=7, a0="foo" either way.  (va_list and associated calls would
be relatively complicated under such an implementation, but it
certainly could be done in a conformant way.)

NetBSD certainly could choose to restrict itself to implementations
where va_list_to_sequential_memory() can be done without needing all
the argument types.  But why?  Is encouraging people to write
nonportable code really that important?

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B