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. > 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. > 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.
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.) More interesting than __null would be to implement nullptr, the real null pointer constant from C++0x. Sebastian _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
