Why is this c code not changing the value of arr[3]?

Question

I am creating an int array and then tricking c into believing that it's an array of short values. I know it's not good practice but I am just trying to understand why this isn't working. Shouldn't this change the value of arr[3] ?

#include <stdio.h>

int main() {
    printf("Hello, World!\n");
    int arr[5];
    arr[0] = 0; arr[1] = 0; arr[2] = 0; arr[4] = 0;
    arr[3] = 128;
    ((short*)arr)[6] = 128; // Shouldn't this change arr[3] ? as 6,7 indices in the arr of short would compromise of arr[3] in arr of ints?
    int i = 0;
    for (i = 0; i < 5; i++){
        printf("%d\n", arr[i]);
    }
    return 0;
}

PS: Here's a deeper clarification: When I cast int array to a short array, it seemingly becomes an array of 10 short elements (not 5). So when I change arr[6], I am changing only the first 16 bits of the int arr[3]. So arr[3] should still change and it is NOT that I am changing it to 128 again and not seeing the change.

FOR CLARIFICATION: THIS CODE IS ONLY FOR EXPERIMENTAL REASONS! I AM JUST LEARNING HOW POINTERS WORK AND I GET THAT ITS NOT GOOD PRACTICE.

Answer 1

Your code has undefined behavior, because you are writing a datum with a declared type through a pointer to a different type, and the different type is not char.

int arr[5];
/* ... */
((short*)arr)[6] = /* ANYTHING */;

The compiler is entitled to generate machine code that doesn't include the write to ((short*)arr)[6] at all, and this is quite likely with modern compilers. It's also entitled to delete the entire body of main on the theory that all possible executions of the program provoke undefined behavior, therefore the program will never actually be run.

(Some people say that when you write a program with undefined behavior, the C compiler is entitled to make demons fly out of your nose, but as a retired compiler developer I can assure you that most C compilers can't actually do that.)

Answer 2

It is changing arr[3], however you are setting it back to 128 so you arent noticing a change. Change the line to:

((short*)arr)[6] = 72;

and you should see the following output:

Also a couple of things to clean up if you are new to C. You can initialize an array to zero by doing the following.

... int arr[5] = { 0 }; arr[3] = 128; ...

Hope this helps!

Answer 3

Have you considered endianness?

EDIT: Now to add more clarity ...

As others have mentioned in the comments, this is most definitely undefined behavior! This is not just "not good practice", it's just don't do it!

Pointers on C is an excellent book that goes over everything you wanted to know about pointers and more. It's dated but still very relevant. You can probably find most of the information online, but I haven't seen many books that deal with pointers as completely as this one.

Though it sounds like you are experimenting, possibly as part of a class. So, here are a number of things wrong with this code:

• endianness
• memory access model
• assumption of type size
• assumption of hardware architecture
• cross type casting

Remember, even though C is considered a pretty low level language today, it is still a high level programming language that affords many key abstractions.

Now, look at your declaration again.

int arr[5]; 

You've allocated 5 ints grouped together and accessed via a common variable named arr. By the standard, the array is 5 elements of at least 2 bytes per element with base address of &arr[0]. So, you aren't guaranteed that an int is 2 bytes, or 4 bytes or whatever. Likewise, as short is defined by the standard as at least 2 bytes. However, a short is not an int even if they have the same byte width! Remember, C is strongly typed.

Now, it looks like you are running on a machine where shorts are 2 bytes and ints are 4 bytes. That is where the endianness issue come into play: where is your most significant bit? And where is your most significant byte?

By casting the address of arr to a short pointer first of all breaks both the type and the memory access model. Then, you want to access the 6th element from the offset of arr. However, you aren't accessing relative to the int you declared arr to be, you are accessing through a short pointer that is pointing at the same address as arr!

These following operations ARE NOT the same! And it also falls into the category of undefined - don't do this ever!

int foo;
int pfooInt;
short bar;
short * pfooShort;

bar = (short) foo;
pfooShort = (short*)&foo;
pfooInt = &foo;
bar = *pfooShort;
pfooShort = (short*)pfooInt[0];

Another thing to clarify for you:

int arr[5];

((short *)arr)[6] ...

This does not transform your int array of 5 elements into a short array with 10 elements. arr is still an int array of 5 elements. You just broke the access method and are trying to modify memory in an undefined manner. What you did is tell the compiler "ignore what I told you about arr previously, treat arr as a short pointer for the life of this statement and access/modify 6th short relative to this pointer."