Compiling #include <stddef.h> #include <crtdefs.h> int* a = NULL without -nobuiltininc yields: test.cc:5:16: error: expected expression int* a = __null; That's because clang's stddef.h defines NULL to __null, but crtdefs.h apparently defines __null to something else. Not sure what the right fix is. Make __clang_null an alternate spelling of __null and define NULL to __clang_null in stddef.h?
Eli, since you said you'd rather not support -nobuiltininc -fsyntax-only: Do you have any opinion which direction to take in this bug?
How about just using "0" when -fms-compatibility is on? It's equivalent except that you'll get slightly worse warnings. __clang_null is ugly, but making it an alias for __null is okay if necessary.
The reverse is an issue too: clang's stddef.h does "#undef __null". However, some ms analysis tool uses __null as an annotation and has a header that defines it to nothing in normal builds. With clang's current stddef, this code breaks: #define __null // Emulate ms header #include <stddef.h> void f(__null void* p) { }
r155490 fixes this by defining NULL to 0. Maybe I'll look into having a __clang_null another day.
Created attachment 13084 [details] __clang_null patch Here's how __clang_null would look, it's very simple. One side effect of this is that clang starts warning on many things where existing code passes NULL for some HANDLE and the HANDLE is an int behind the scenes – but even MSDN docs say to use NULL (e.g. http://msdn.microsoft.com/en-us/library/windows/desktop/aa363686(v=vs.85).aspx)