On Wed, Aug 20, 2008 at 8:06 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 20, 2008 at 8:34 PM, Douglas Davidson <[EMAIL PROTECTED]> 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):

[EMAIL PROTECTED]:~]% cat test.c
#include <stdio.h>

int main() {

  printf("sizeof(NULL) == %zu\n", sizeof(NULL));
  return 0;
}
[EMAIL PROTECTED]:~]% cc test.c -arch i386 && ./a.out
sizeof(NULL) == 4
[EMAIL PROTECTED]:~]% cc test.c -arch x86_64 && ./a.out
sizeof(NULL) == 8

-- 
Clark S. Cox III
[EMAIL PROTECTED]
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to