Re: must use gcc builtin?

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Feb 23, 2012 at 09:30:47PM -0500, James K. Lowden wrote:
 > I will attempt to show why these claims are faulty.  I'm either on very
 > solid ground, or NetBSD is seriously broken.  Why?  
 > 
 > #ifdef __GNUC__
 > #define _BSD_VA_LIST_    __builtin_va_list /* GCC built-in type */
 > #else
 > #define _BSD_VA_LIST_    char *    /* XXXfvdl should be ok? */ 
 > #endif
 > 
 > That code doesn't depend on x86.  It depends on GNU.  All I need is
 > another C compiler for x86, and my va_list is magically char* again.

So, if you compile with a compiler that it doesn't support, NetBSD
provides a definition that might work. Or might not. What's your point
here?

 > That's what I thought Joerg was referring to.  It's a mistake to
 > equate stdarg with "stack", and it's mistake to equate "stack" with
 > "sequential memory not on the chip".  Therefore it's a mistake to say
 > stdargs can't be implemented without compiler builtins on any
 > architecture.

Of course it can be implemented without compiler builtins. Go rake up
a gcc 2.7 install (or maybe you need 2.6 or 2.5, I forget just how far
back) and look at how it's done there. Providing a uniform set of
compiler builtins instead of all that crap was a step forward, not a
step back.

However, you've changed the subject. You're now talking about whether
stdarg.h is implemented with compiler builtins or cpp hackery. That
makes no difference to whether the code you've cited is correct. It
still isn't.

There are only four operations defined on va_list: va_start, va_end,
va_copy, and va_arg. Anything else you attempt to do is, ipso facto,
undefined. The code you've cited is assuming that va_list is a
pointer, which it isn't required to be, that it points to a memory
block containing (all the) arguments, which is not necessarily the
case, and that pointer arithmetic on such a pointer, if it were to be
a pointer, produces useful results, which may not be the case either.

From what I can tell you seem to be intending to argue that the C
standard should be changed to require this code to work, and that
~every platform other than i386 and I guess m68k should rearrange its
calling conventions changed in order to accomodate you.

You haven't actually made this argument yet. But, don't bother --
calling conventions aren't going to change and the extra behavioral
guarantees you're asking for aren't possible on most platforms.

 > I'm sympathetic to arguments for minimalism and standards compliance.
 > But that shouldn't mean that perfectly fine C should not compile just
 > because the standard doesn't impose the requirement that it be
 > compilable.  

How is code with no defined meaning "perfectly fine"? But anyway,
undefined code in fact usually does compile. Usually though this is
considered a bad thing.

-- 
David A. Holland
dholland%netbsd.org@localhost