Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare
Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare
- Subject: Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare
- From: Michael Ash <email@hidden>
- Date: Wed, 28 Jan 2009 12:08:50 -0500
On Wed, Jan 28, 2009 at 6:00 AM, Jeremy Pereira <email@hidden> wrote:
>
> On 27 Jan 2009, at 23:07, Graham Cox wrote:
>
>>
>> On 28 Jan 2009, at 2:24 am, Jeremy Pereira wrote:
>>
>>> Yes. That is correct, but since buffer is already a pointer to the first
>>> byte of the array and then you are taking a reference to it, key will end up
>>> containing the address of the buffer. You really need:
>>>
>>>> uint key = *(uint*)buffer;
>>>
>>
>>
>> That's incorrect. Or rather, in this case it doesn't make any difference,
>> but the use of '&' is more general as it works whether buffer is an array or
>> not.
>>
>>
>> When you declare:
>>
>> uint8 buffer[8];
>>
>> You've reserved 8 bytes on the stack. Whether you use 'buffer' or
>> '&buffer' you obtain the same address, as C treats array variables as
>> pointers. But:
>
> Having tried it just now, I stand corrected.
>
> However, I would argue that this is the C compiler behaving in a
> deliberately inconsistent way, since in C, arrays and pointers are supposed
> to be the same thing. As buffer is actually a constant, taking its address
> should really result in a compiler error in the same way as int a = &123;
It's not the C compiler, it's the language. This behavior is required
by the language specification, so the compiler can't help but comply.
The pointer/array duality is one of the most confusing things in C
because it is somewhat inconsistent, but it's also quite
straightforward.
Let's say you declare an array:
int x[32];
Now if you use the symbol "x", it has type int*. As such, it's
perfectly valid to write something like x+2 (gives you a pointer to
the 3rd element of the x array), to pass x directly to functions which
take pointers, and to cast it to another pointer type. It's even legal
to write *x, which gets you the first element of the array.
What happens when you use "&x"? That gives you the same value *but of
a different type*. The type of &x is int*[32], i.e. a pointer to an
array of 32 ints. You can declare a pointer of this type using amusing
and bizarre syntax:
int (*y)[32] = &x;
This has consequences for pointer arithmetic. (&x)+2 is not the same
as (x+2); the latter gives you the 3rd element of the array, the
former gives you a pointer off into hyperspace, where the 3rd array
would be if you stacked 3 (or more) of these things up contiguously.
Now we can talk all we want about how these things "should" work, and
I agree that this behavior can be kind of odd, but the fact is that
it's a part of the language, a part of the standard, it is how it is,
and it's not going to be changed.
Mike
_______________________________________________
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