[cfe-commits] r58685 - /cfe/trunk/lib/Headers/stddef.h

Chris Lattner clattner at apple.com
Tue Nov 4 06:12:41 PST 2008

On Nov 4, 2008, at 6:03 AM, Sebastian Redl wrote:

> Chris Lattner wrote:
>> This is fine in the short term, but I don't think this will work  
>> in  general.
> It's the way every C++ compiler out there does it.

0 or 0L?

>>  Consider if you have:
>> somevarargsfunction(1, 2, NULL);
>> This will pass as an int, instead of as a pointer.  This matters on  
>> 64- bit targets.
> It matters everywhere for overloading. C++ programmers expect it.  
> Oh, and we avoid varargs functions if we can.

Avoiding varargs isn't really an option :), we have to support things  
that are included in the language.

>> GCC has a strange __null extension that it uses for C++ mode,  
>> should  we add support for it?
> It would be nice to have, but the extension doesn't do what you  
> think. __null is actually an integer constant expression with value  
> 0, which emits a warning if it is converted to int. typeid(__null)  
> gives you the type ID of long.
> __null isn't designed to make the varargs code safe, but to notify  
> the programmer when he uses NULL in an actual integer context.

Ahhh, interesting, I didn't realize that.

> Perhaps we should define NULL as 0L, though. While GCC's stddef.h  
> defines NULL to be 0 if __GNUG__ is not defined and the language is C 
> ++, I believe that to be an inconsistency they simply haven't  
> noticed because __GNUG__ is always defined.
> Note that VC++ 7.1 (Visual Studio.Net 2003) defines NULL to be 0.  
> They may have changed this to 0LL in those versions that actually  
> support 64-bit targets, though. (VC++ has 32-bit longs under 64-bit  
> architectures, so 0L wouldn't be sufficient.)

Ah, ok, this is complicated.  Why isn't even null easy? :)


More information about the cfe-commits mailing list