[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? :)
-Chris
More information about the cfe-commits
mailing list