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.

__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)

mentioned in issue llvm/llvm-bugzilla-archive#13707