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

[Chris Lattner]

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? :)

-Chris