I suspect that there is a language issue here. What exactly do you
mean by "alignment"?
On Wed, Aug 20, 2008 at 9:10 PM, mm w <[EMAIL PROTECTED]> wrote:
> great alignement
>
> On Wed, Aug 20, 2008 at 8:32 PM, Clark Cox <[EMAIL PROTECTED]> wrote:
>> 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/openspecies%40gmail.com
>>
>> This email sent to [EMAIL PROTECTED]
>>
>
>
>
> --
> -mmw
>
--
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]
