🚀 go-pugleaf

flaps@dgp.toronto.edu (Alan J Rosenthal) writes:

>dat@thinkage.on.ca (David Adrien Tanguay) writes:
>>How is this any different from the array example?  p may point
>>outside a[1], but it is still within the a object.  Similarly, ...
>>is outside the f->s object but within the malloc object.
>
>The point is, "int a[5][5];" doesn't give you 25 ints, it gives you five arrays
>of five ints each.  "(int(*)[5])malloc(5*sizeof(int[5]))" gives you
>sizeof(int)*25 bytes which are ALSO five arrays of five ints.
>
>The first looks like this:
>	int[5][5]:
>	    int[5]:
>		int
>		int
>		int
>		int
>		int
>	    int[5]:
>		...
>	    ...
>
>And the second looks like this:

     malloc(25):
>	char
>	char
>	char
>	char
>	...
>
>Now that cast magically makes the second be close enough to the first in
>outward appearance for all intents and purposes, but it's still the second
>underneath.  Obviously in almost all compilers the memory layout will be the
>same.  However, an environment such as Saber-C should be free to keep track of
>the details and that's why I've always thought that this is a good
>interpretation ruling.
>
>I'm not sure what you get when you take a pointer to that array five of array
>five of int, cast it to a (char *), then cast it to a (int(*)[5]).

This sounds like a fairly reasonable explanation, but I still have some
questions.

Do same considerations would apply if you tried to use a char[5][5] 
array as a char[25] array? It sounds like you would say they
do. What about casting a char[25] array to a char[5][5] array?

From what you're saying, the reason that casting the return
value from malloc succeeds is only because malloc is "magic".

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!