[cfe-dev] Fixing selector types on the GNU runtime

[Mike Stump]

On Jan 20, 2009, at 5:46 PM, David Chisnall wrote:
> The question at hand is whether, according to the C++ spec, NULL,  
> when passed to a variadic function, will always be a 0 pointer.

Odd, the issue you seemed to have raised was relating to warnings on  
freebsd, not some theoretic point about NULL.

Anyway, technically, no.  However, dusty deck code requires this of  
implementations.  The standard arguably should just require this.  I'm  
surprised posix didn't just insist, sometimes they do.

> If you have one, then it's a bug in g++ combined with the FreeBSD  
> headers.

One doesn't need a reference for this to be a bug in FreeBSD.

> If you don't, then it's a fault in LLVM's usage of NULL, which  
> happens not to matter on some platforms.

Arguably, the usage of NULL is theoretically bad:

   http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr

But, I'm deeply against causing major pains for 99% of the people that  
can manage to work on a quality implementation, just because someone  
can pedantically come up with a broken system that trivially can just  
be fixed:

#ifdef FreeBSD
#ifdef __GNUG__
   #undef NULL
   #define NULL __null
#endif
#endif

even if we needed to do this on the client side.

However, if you want llvm's sources to be pedantically correct, just  
turn on -Wstrict-null-sentinel and prest, everyone will be hit by  
this, not just you.  I'm not advocating that however.

>>> If NULL is #define'd to __null on some platforms, then this is  
>>> great, but isn't it a GCC extension?
>>
>> I'd call it a private internal implementation detail of the  
>> compiler.  The compiler is implemented such that for proper  
>> operation, NULL _must_ be __null.
>
> No, the compiler is implemented such that, for NULL to be a pointer  
> when passed as an argument to a  variadic function it must be __null.

No, the compiler is implemented such that NULL is __null.  Honest.

> Since the C++ spec appears to allow NULL to be 0 or 0L,

No, it does allow that.  Read the standard again.  The specs says that  
g++ gets to define it, and g++ defines it as __null.  Since it is  
defined to be __null, it _cannot_ be any other value, including 0 or 0L.

> for compatibility with C code and the C++ type system, this means  
> that passing NULL as a pointer when it is an argument to variadic  
> functions is either a special case in the spec or a GCC extension.

We call it a quality of implementation.

> I have never heard of NULL having any special behaviour

Welcome to g++.

> The fact that there is no such behaviour was cited as the main  
> motivation for the introduction of one of the extensions added in C+ 
> +0x.

:-(  I'm skeptical that nullptr is the right solution.

>>> I was under the impression that the LLVM coding conventions stated  
>>> that GCC extensions were to be avoided so that it could be easily  
>>> portable to compilers.
>>
>> llvm uses NULL.  NULL is not a gcc extension.
>
> Totally irrelevant.  Once again, the question is whether NULL is  
> guaranteed to be a type which will be passed as a pointer or a  
> pointer-sized integer to variadic functions, not whether NULL is in  
> the standard.

No, technically you need to do: (char *)NULL.

So, what are you interested in, the theoretics of hard core  
pedantictry or the engineering realities of having FreeBSD be warning  
free?