Question

i.e. if we cast a C or C++ unsigned char array named arr as (unsigned short*)arr and then assign to it, is the result the same independent of machine endianness?

Side note – I saw the discussion on IBM and elsewhere on SO with example:

unsigned char endian[2] = {1, 0};
short x;
x = *(short *) endian;

…stating that the value of x will depend on the layout of endian, and hence the endianness of the machine. That means dereferencing an array is endian-dependent, but what about assigning to it?

*(short*) endian = 1;

Are all future short-casted dereferences then guaranteed to return 1, regardless of endianness?

---

After reading the responses, I wanted to post some context:

In this struct

struct pix { 
    unsigned char r; 
    unsigned char g;
    unsigned char b; 
    unsigned char a; 
    unsigned char y[2]; 
 }; 

replacing unsigned char y[2] with unsigned short y makes no individual difference, but if I make an array of these structs and put that in another struct, then I’ve noticed that the size of the container struct tends to be higher for the “unsigned short” version, so, since I intend to make a large array, I went with unsigned char[2] to save space overhead. I’m not sure why, but I imagine it’s easier to align the uchar[2] in memory.

Because I need to do a ton of math with that variable y, which is meant to be a single short-length numerical value, I find myself casting to short a lot just to avoid individually accessing the uchar bytes… sort of a fast way to avoid ugly byte-specific math, but then I thought about endianness and whether my math would still be correct if I just cast everything like

*(unsigned short*)this->operator()(x0, y0).y = (ySum >> 2) & 0xFFFF;

…which is a line from a program that averages 4-adjacent-neighbors in a 2-D array, but the point is that I have a bunch of these operations that need to act on the uchar[2] field as a single short, and I’m trying to find the lightest (i.e. without an endian-based if-else statement every time I need to access or assign), endian-independent way of working with the short.

Answer 1

Yes, all future dereferences will return 1 as well: As 1 is in range of type short, it will end up in memory unmodified and won’t change behind your back once it’s there.

However, the code itself violates effective typing: It’s illegal to access an unsigned char[2] as a short, and may raise a SIGBUS if your architecture doesn’t support unaligned access and you’re particularly unlucky.

However, character-wise access of any object is always legal, and a portable version of your code looks like this:

short value = 1;
unsigned char *bytes = (unsigned char *)&value;

How value is stored in memory is of course still implementation-defined, ie you can’t know what the following will print without further knowledge about the architecture:

assert(sizeof value == 2); // check for size 2 shorts
printf("%i %i\n", bytes[0], bytes[1]);