On Wed, Jan 28, 2009 at 6:00 AM, Jeremy Pereira <a...@jeremyp.net> 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 (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 arch...@mail-archive.com
