Re: !foo vs foo == nil
Re: !foo vs foo == nil
- Subject: Re: !foo vs foo == nil
- From: "mm w" <email@hidden>
- Date: Wed, 20 Aug 2008 21:10:52 -0700
great alignement
On Wed, Aug 20, 2008 at 8:32 PM, Clark Cox <email@hidden> wrote:
> On Wed, Aug 20, 2008 at 8:06 PM, Michael Ash <email@hidden> wrote:
>> On Wed, Aug 20, 2008 at 8:34 PM, Douglas Davidson <email@hidden> wrote:
>>> Well, after all, zero is zero, how much difference can it make? Quite a
>>> bit, as it turns out, since in 64-bit one of them is four bytes of zero, and
>>> the other is eight bytes of zero. If you're just comparing against NULL, it
>>> doesn't matter, but if you're using it in something where size counts--say,
>>> a list of vararg arguments--then it matters a lot. It's not easy to debug,
>>> though, because who would think that you need to distinguish one NULL from
>>> another?
>>
>> It is a little known fact that when passing NULL (and by extension nil
>> or Nil) as a parameter to a vararg function, you *must* cast it to the
>> appropriate pointer type to guarantee correct behavior.
>>
>> Interestingly, Apple's vararg methods which use nil as a terminator
>> (such as dictionaryWithObjectsAndKeys:) make no mention of this in
>> their documentation, and have a great deal of officially sanctioned
>> sample code which doesn't use such a cast. (And none of my code uses
>> it either.) I suppose Apple must be implicitly making a stronger
>> guarantee about the pointer-ness of nil than the C language makes
>> about NULL.
>
> GCC does that for you (i.e. the NULL defined by GCC is already typed
> to a pointer):
>
> [ccox@ccox-macbook:~]% cat test.c
> #include <stdio.h>
>
> int main() {
>
> printf("sizeof(NULL) == %zu\n", sizeof(NULL));
> return 0;
> }
> [ccox@ccox-macbook:~]% cc test.c -arch i386 && ./a.out
> sizeof(NULL) == 4
> [ccox@ccox-macbook:~]% cc test.c -arch x86_64 && ./a.out
> sizeof(NULL) == 8
>
> --
> Clark S. Cox III
> email@hidden
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
--
-mmw
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden