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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
