unions, alignment, int pointers, wow!

[mhrodri]

Following my first post about alignment of int pointers (April 4th), now I find that unions work ok. Let me summarize:

I lately discovered that in some compilers/hardware you cannot cast a char pointer into an int pointer if you don´t pay attention to alignment. The following will not work (at least everywhere):

char Message[10] = { 0x7F, 0x00, 0x00, 0x00, 0x01 /*, ...*/ };
...
int addr = *(int *)&Message[1] ;

What I discovered now is that the following DO work, to my surprise, where the latter don´t:

struct meaning {
char gap ;
int address ;
char remaining[5] ;
} ;

union {
char message[10] ;
struct meaning data ;
} um ;

... /* copy into message */
memcpy (um.message, Message, 10) ;

int addr = um.data.address ;

Could anybody explain to me why? Why cannot I cast a pointer to unaligned int, but YES can I map into a union and access to the int part even not aligned?
I was told not to expect good results in non-aligned pointers, that the standard says "undefined behaviour". Is it explicitly indicated in the standard, when you refer to unions, that the compiler has to solve even in non-aligned situations?
Many thanks...
...marcelo

[anduril462]

Check out the following section from the Wikipedia article: Data structure alignment - Wikipedia, the free encyclopedia. It explains the struct alignment pretty well. As for unions, IIRC, it is aligned according to the biggest type in there. In your case, the struct (because of padding between gap and address members) forces the union to be aligned on an appropriate boundary, probably something that's a multiple of 4. In a union, all members start at the same address and are overlapping, so message ends up being aligned the same as data.

[CommonTater]

A union is a type of struct. But instead of creating variables beside each other it creates them on top of eachother. The result is a block of memory the size of the largest element in the struct. Since the various elements are piled on top of eachother (i.e. occupying the same memory space) putting something in one means you get something out of the other. Alignment is a result of the way the union is sized by the compiler.

In fact that is one of the good uses for unions...

union t_Pile
  { unsigned char bytes[sizeof(int)];
     unsigned int   integer;
   } Pile;

Pile.integer = 1000;

unsigned char x = Pile.bytes[1]; // retrieve the second byte from the integer.

[nonoob]

The short answer is that you are actually doing the following:

struct meaning {
char gap ;
char padding[3]; /* inserted by the compiler so that next element starts at multiple of 4 or 8 whatever is native machine */
int address ;
char remaining[5] ;
} ;

This is for illustration purposes only.

[grumpy]

You've got it wrong. Unions don't magically fix alignment concerns. Structs do though.

All members of a struct are required to be addressable - which, if there is a problem with alignment of types, means the compiler has to introduce padding between struct members.

Using such a struct as a member of a union does not change that.

If it's happening in your case, one side effect is that sizeof(struct meaning), and therefore sizeof your union, exceeds 10 - there will be padding between gap and address in your struct meaning

[Salem]

I think you need to check the alignment of each member in your struct.

$ cat bar.c
#include <stdio.h>
#include <stddef.h>
#include <stdlib.h>

typedef struct meaning {
char gap ;
int address ;
char remaining[5] ;
}meaning;

int main ( ) {
  printf("Size=%zd\n", sizeof(meaning));
  printf("Offset=%zd\n", offsetof(meaning,address));
  return 0;
}
$ gcc bar.c
$ ./a.out 
Size=16
Offset=4

On most machines, your struct is neither 10 bytes long, nor is your integer at offset 1.

To pack as you want, you typically need something like a pragma (or attributes in gcc)

$ cat bar.c
#include <stdio.h>
#include <stddef.h>
#include <stdlib.h>

#pragma pack(1)
typedef struct meaning {
char gap ;
int address ;
char remaining[5] ;
}meaning;

int main ( ) {
  printf("Size=%zd\n", sizeof(meaning));
  printf("Offset=%zd\n", offsetof(meaning,address));
  return 0;
}
$ gcc bar.c
$ ./a.out 
Size=10
Offset=1

Whilst this gets the int to the correct place, you'll find that any code which accesses that int will be "slugged" to take into account it's unaligned position in memory.

The most reliable method of solving your problem is something like

myInt = (int)buff[1] << 24 | (int)buff[2] << 16 | (int)buff[3] << 8 | (int)buff[4];

Which works regardless of endian issues on the host machine, so long as you know the endianess of the input message.

If you know the endian is the same, you can short-cut to

memcpy( &myInt, &buff[1], sizeof(myInt) );

[itCbitC]

Why not print out the address of um.data.address to see if it is aligned on its natural boundary.
As noted, struct members have internal padding to align each type on its natural boundary, and
Tail padding to make the struct a multiple of its most restrictive type which in this case is an int.

[mhrodri]

No, I can assure no padding is added. You see, I have a char vector that memcpy to the char vector part of the union, and then I can access to the second-third-fourth-fifth bytes with the second part of the union, where I see it as an integer. Marvellous. But I don´t understand, because the compiler/hardware don´t let me do it if I use a pointer. So, as I can understand, I am really accessing an int not aligned, with the trick of using a union. Does it make sense?

[itCbitC]

No, I can assure no padding is added.

The compiler pads the struct behind-the-scenes, not the programmer.

You see, I have a char vector that memcpy to the char vector part of the union, and then I can access to the second-third-fourth-fifth bytes with the second part of the union, where I see it as an integer. Marvellous.

Yep! because union members share the same storage, so memcpy() can fill um using char Message[] as source.

But I don´t understand, because the compiler/hardware don´t let me do it if I use a pointer. So, as I can understand, I am really accessing an int not aligned, with the trick of using a union. Does it make sense?

Nope! you're mistaken, because the int is aligned. The previously defined struct takes care of that.
Print out the address in both cases and you'll see that one is nonaligned while the union one isn't.

[Salem]

Without you saying which compiler you're using, and taking your word that the size of your structure is 10 bytes, then the compiler may (previously, I said will) be generating special code to access the unaligned integer.

If you're on an x86, then it is a somewhat unusual processor in that it does allow unaligned accesses. Doing a bit of digging around, the earlier models (before the 386), there was a performance hit of a few clock cycles for accessing unaligned words. The modern processors all seem to manage it in one cycle anyway.

[nonoob]

Some micro-controllers may not allow unaligned multi-byte access. The addressing just isn't set up to allow odd byte address. In that case the compiler that's intended for that platform is right to issue severe error messages if attempted because it won't be able to generate correct machine code.

[mhrodri]

Well, I can confirm the following, after more detailed revision. Let me rewrite the example:
char original_data[10] = { 0x7F, 0x00, 0x00, 0x00, 0x01, 0 } ;

The second-third-..-fourth byte defines an integer number. The following will NOT work:
int addr = *(int *)original_data[1] ;

but the following YES, it works:
union {
char bytes[10] ;
struct {
char header ;
int address ;
} interpret ;
} u_data ;
memcpy (u_data.bytes, original_data, 10) ;
addr = u_data.interpret.address ;

In this latter code you can access no-aligned int. I have looked at the assembler generated by the compiler, and I see the difference. I can figure out that the compiler correctly access the int because I saw shifts, and two accesses.
So, sadly, the lazzy compiler does not make any effort when dealing with pointers, but in unions it really accesses what we expect. Why would it be? Perhaps a strict stick to the standard?
Thank you everyone for your time.

[Salem]

It might actually help if you told us which compiler you're using.

FWIW, some embedded compilers may favour compactness of data structures at the expense of access speed. There should (may) be an option to modify that behaviour.

> So, sadly, the lazzy compiler does not make any effort when dealing with pointers
Why should it kill the performance of every pointer access, just on the off-chance it may be unaligned?

[mhrodri]

avr-gcc, the compiler

ok, thank you

[Salem]

I had a look through my local gcc manual for the variable attributes, hoping to be able to do something like this.
But it would seem to be not the right thing to do.

int *mySpecialPointer __attribute__ ((aligned (1)));
mySpecialPointer = (int*)&original_data[1] ;
int addr = *mySpecialPointer;

The general idea being to signal to the compiler that this particular int pointer is a bit special, and generate more conservative code when it comes to dereferencing it.


You can do a lot of weird stuff with attributes, so it might be worth checking out.

It might be worth checking to see if your local compiler (tuned for AVR specifically) has such a feature.