[cfe-dev] Fixing selector types on the GNU runtime

[David Chisnall]

On 19 Jan 2009, at 21:29, Chris Lattner wrote:

>
> On Jan 19, 2009, at 1:25 PM, Mike Stump wrote:
>
>> On Jan 18, 2009, at 3:01 PM, David Chisnall wrote:
>>> NULL is #defined as 0 for C++ on FreeBSD.
>>
>> This is wrong.  If you're using a recent g++ based compiler, NULL
>> should be __null in g++.  :-)
>>
>>> I get missing sentinels in a huge numbers of missing sentinel errors
>>> when
>>> building LLVM.
>>
>> And do they go away if you have NULL defined correctly?
>
> I agree with Mike here.  FreeBSD should be using __null or 0L.  I  
> don't think we should switch CGObjCGNU to using a different idiom  
> than the rest of the code base, and I don't want to change the  
> entire LLVM world to avoid NULL in varargs.

I can't find a copy of the spec online (and I leant my paper copy to  
someone a while ago), but every reference I can find says that NULL  
may be a #define for 0 or 0L.  Neither of these is guaranteed to be  
pointer sized or bigger (although 0L is on most platforms, with Win64  
being the most notable exception that springs to mind and caused a lot  
of breakage for code that assumed sizeof(long) >= sizeof(void*)).  As  
I recall, the rationale for NULL in C++ was compatibility with C code,  
and its use was discourage in new C++ code.

If NULL is #define'd to __null on some platforms, then this is great,  
but isn't it a GCC extension?  I was under the impression that the  
LLVM coding conventions stated that GCC extensions were to be avoided  
so that it could be easily portable to compilers.

I don't really care whether this part of the diff is committed - the  
part I am interested in is the part that makes clang able to compile  
Objective-C code on non-Apple platforms again - but it would be nice  
to be able to compile both clang and LLVM without myriad warnings.

David