Re: FreeBSD 4.0

[Zack Weinberg <zack AT bitmover.com>]

"David O'Brien" wrote:
> > May I suggest that stdarg.h/varargs.h be modified to #define
> > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to
> > limit it to FreeBSD?  
> 
> Why not do it the other way around?
> 
>     #define __gnuc_va_list _BSD_VA_LIST_

Because the "real" type is __gnuc_va_list.  Doing it your way won't do
what you want.  I hope you don't have system headers that typedef
_BSD_VA_LIST_ without reference to gcc's stdarg.h - for one thing, we
probably just irrevocably broke them.

> Please, please lets not require the dinking of many system headers.
> Please also remember GCC is the base compiler in BSD and the number of
> things that have to be changed when native'ifing the compiler the better.

I believe #define _BSD_VA_LIST_ __gnuc_va_list will solve your problem
without any dinking of BSD libc headers.

> > (Is this needed by Net/OpenBSD too?)  This is simpler and less fragile
> > than adding stuff to fixinc.
> 
> This is a 4.4BSD thing.  It thus affects all of BSD.

Is there any macro which is defined by all 4.4-derived systems?

> > For complicated reasons related to similar interactions with glibc's
> > headers, I'd personally like to see the typedef name be __va_list, and
> > __gnuc_va_list a #define as well.
> 
> Can you explain these interactions?  I really doubt the BSD headers are
> as intertwined.

The intertwining with glibc is not as bad as you might think, and
__gnuc_va_list is actually the least bad part.  For real issues, try
to figure out what wint_t is doing in stddef.h, or how limits.h works.

The problem with __gnuc_va_list is primarily aesthetic.  Everyone has
to agree on the underlying typedef name because of C++ mangled names.
Therefore I would like the underlying typedef name to be
compiler-neutral.  People do want to use glibc with compilers other
than gcc.

zw