NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/std/c/2606

Internet Message Format | 1992-09-10 | 1.6 KB

Path: sparky!uunet!elroy.jpl.nasa.gov!usc!rpi!utcsri!dgp.toronto.edu!flaps
Newsgroups: comp.std.c
From: [e-mail] (Alan J Rosenthal)
Subject: Re: struct hack, and other out-of-array references
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: 11 Sep 92 05:24:38 GMT
Lines: 37

[e-mail] (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:
    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]).