segfault when accessing array after typecasting to a different type

Question

so I know you can do things like this:

 char c[4];
 int *p;

 p = (int*)c;
 p[0] = 1;

to set all the character values at once. But I went a step further and did:

char c[1][4];
int **p;

p = (int**)c;
p[0][0] = 1;

and it segfaults. Could someone explain why this is happening?

While an array naturally decays to a pointer to its first element, an array of arrays is *not* the same as a pointer to a pointer. In this case `c` is equal to `&c[0]` which is of type `char (*)[4]`. See e.g. [this old answer of mine](https://stackoverflow.com/questions/18440205/casting-void-to-2d-array-of-int-c/18440456#18440456) for more information. — Some programmer dude, Sep 25 '17 at 07:17
@Jean-FrançoisFabre ok but what is it? To my understanding c[1][4] meant i was declaring a pointer to a list of 1 pointers in a row which each were pointing to 4 characters in a row. Sorry i just am confused — Theo Walton, Sep 25 '17 at 07:18
@TheoWalton nope. Static 2D array where the compiler computes the actual index for you in a `numrows*i+j` fashion. — Jean-François Fabre, Sep 25 '17 at 07:19
Also, you're breaking strict aliasing in the first example so this is already undefined behavior. — Hatted Rooster, Sep 25 '17 at 07:19
@RickAstley `char` should be an exception to the strict aliasing rule. — mch, Sep 25 '17 at 07:22
@mch No, the exception is inspection of a type T through a char pointer, not the other way around. — Hatted Rooster, Sep 25 '17 at 07:27
@Jean-FrançoisFabre -- "the actual index for you in a `numrows*i+j` fashion": don't you mean `numcols * i + j`? — ad absurdum, Sep 25 '17 at 13:07
@Jean-FrançoisFabre -- I have been bitten by that moody fashion more than once ;) — ad absurdum, Sep 25 '17 at 13:40

Jean-François Fabre · Accepted Answer · 2017-09-25T15:35:17.937

you were lucky in your first example: alignment constraints on some CPUs (ex: on legacy 68000) could have segfaulted right away... Not to mention not portable code because of endianness issue.

That said, c[1][4] isn't an array of pointers. It's a 2D array (of 4 bytes storage). So dereferencing it twice like you're doing is bound to fail (your previous technique probably "works", though).

Lying to the compiler like this isn't really an option. Also note that int isn't guaranteed to be 4 bytes long, so better use standardized types like uint32_t (unsigned 32-bit integer from stdint.h)

To set data faster, you could use memcpy, example:

uint32 v = 1;
memcpy(c,&v,sizeof(v));

Could you explain "alignment constraints on some CPUs could have segfaulted right away" — qwn, Sep 25 '17 at 07:19

segfault when accessing array after typecasting to a different type

1 Answers1