sizeof() bug?

[fredvr]

Looks like sizeof() reports the wrong size for the Union below.

Code: Select all

union {
	unsigned char  			byte[0];   
	struct {
		struct {  
			unsigned char	cmd;         // 1 byte
			float			amount;    // 4
			float			speed;       // 4
			float			accel;        // 4
			float			pos;           // 4
			unsigned char   dir;            // 1
		} exec;
		struct { 
			unsigned char 	lastCmd;               // 1 byte
			unsigned char	lastExecStat;        //  1 byte
			float			currPos;               //  4 bytes
			struct {                                   
				unsigned char fwd 	       :1;
				unsigned char moving       :1;
				unsigned char idle 	       :1;
				unsigned char sleep         :1;
				unsigned char pwrSave	:1;				
			} bits;			                     // 1 byte
		} stat;
	} flds;
} I2Cbuf;

Because I need to transfer the content by copying this buffer by looping through byte[0] .. byte[ sizeof(I2Cbuf) -1 ] I wanted to check if the union is setup correctly starting by looking at it's size using the code below.

The results are not what I expected to be and it looks like sizeof() is not reporting consistent values here..

Code: Select all

i = sizeof( I2Cbuf.flds );
// i -> 36bytes  which would be the size of  I2Cbuf......

i= 0;
i += sizeof( I2Cbuf.flds.exec.cmd );
i += sizeof( I2Cbuf.flds.exec.amount  );
i += sizeof( I2Cbuf.flds.exec.speed ); 
i += sizeof( I2Cbuf.flds.exec.accel );
i += sizeof( I2Cbuf.flds.exec.pos );
i += sizeof( I2Cbuf.flds.exec.dir );
// i -> 18   which is correct IMHO and should be similar to I2Cbuf.flds.exec 
		
i = sizeof( I2Cbuf.flds.exec );	
// i-> 24.....!!!!!!

i= 0;
i += sizeof( I2Cbuf.flds.stat.bits );
i += sizeof( I2Cbuf.flds.stat.lastCmd );
i += sizeof( I2Cbuf.flds.stat.lastExecStat );
i += sizeof( I2Cbuf.flds.stat.currPos );
//i -> 7   which is correct IMHO

however:
i = sizeof( I2Cbuf.flds.stat );
//i -> 12  !!!!!!!!

I would think the size of I2Cbuf.flds should be 18+7= 25 and not 36..
I'm missing something here..?

Using v6.1.1

[tankist02]

Data alignment?

[fredvr]

First of all, I'm pretty unexperienced so I can easily misjudge stuff and my assumptions can be wrong...

But for me I don't have the feeling this difference in reported memory usage is caused by data alignment:
- I tried to fix the array I2Cbuf.byte[0] to I2Cbuf.byte[30]. This field is in the union the counter part of I2Cbuf.flds and share the same memory.
I assume (..) that byte[30] is always one memory block and not spread because of alignement. exact the same result (36 bytes in total)
- I can imagine that some allignment is involved but not causing 24 bytes to actualy use 36bytes which exceeds 1 byte overhead for each field average even when there are several single byte fields involved..

If it really is caused by data allignment then the use of struct/union seems to be very,very, very inefficient in memory use. As far as I know there is not much special in what I´m doing here, I think.

(For me it is important to keep this buffer (I2Cbuf) as compact as possible because it's total is limited to 32bytes max.)

[Gibbon1]

If you are using gcc what you are looking for is

typedef struct __attribute__((packed))
{
uint8_t something;
uint32_t something_else;
} 5byte_size_t;

Without packed attribute you have no idea how the compiler is going to lay the struct out in memory. Usually the compiler optimizes for speed not space. Which means aligning everything on a word boundary, so your struct will have gaps.

When I switched code from an AVR to an ARM I had to add a bunch of packet attributes.

A gotcha: On some ARM processors volatile and packed may result in seg fault because volatile says, every access must be done in a single read or write but the uP can't do a single read or write to an unaligned word, faced with that the compiler will emit code to do an single unaligned access (and emits a warning).

[fredvr]

so it is really an allignment issue...

I played a bit around with the __attribute __ and the size shrinked from 36 with 6 bytes to 30 bytes max.
Adding the attribute at the top of the struct was not enough to let it shrink these 6 bytes. It was necessary to add this 'attribute' to every underlaying struct aswell.

Still 5 bytes more than the sum of the individual fields is though. Can't get it more compact using __attribute__
Glad to know about the existance of this attribute now, though. Something to keep in mind

Compiled the same union in Arduino IDE (AVR). Here sizeof() reports the 25bytes even without __attribute__
I add it anyway to be sure to get the max out of it.

[Gibbon1]

I use typedef stucts with the packed attribute a lot for casting buffers to some meaningful data structure (I wish C had little_indian big_indian attributes)

In your case perhaps the structures with bitfields are causing the size to be larger than expected.

I never use bitfields, instead I use macro's to define bit masks.

// Like this
#define CLOCK_EN (1<<7)

if(flags & CLOCK_EN)
do_something();

Anyway not much of a codelite question.

[Alix]

The original problem is really a data aligment problem. Here is how the compiler implements your structure (look at the gaps):

Code: Select all

    union {
       unsigned char           byte[0];   
       struct {
          struct { 
             unsigned char   cmd;         // 1 byte
             char          gap1[3];       // 3 bytes
             // float must be aligned on 4-byte boundary
             float         amount;    // 4
             float         speed;       // 4
             float         accel;        // 4
             float         pos;           // 4
             unsigned char   dir;            // 1
          } exec;
         char        gap2[3];        // 3 bytes
         // next structure must be aligned on 4-byte boundary because of the float
          struct {
             unsigned char    lastCmd;               // 1 byte
             unsigned char   lastExecStat;        //  1 byte
             char          gap3[2];               // 2 bytes
             // float must be aligned on 4-byte boundary
             float         currPos;               //  4 bytes
             struct {                                   
                unsigned char fwd           :1;
                unsigned char moving       :1;
                unsigned char idle           :1;
                unsigned char sleep         :1;
                unsigned char pwrSave   :1;            
             } bits;                              // 1 byte
          } stat;
          // the whole structure contains a multiple of its minimal alignment (4 bytes)
          chat gap4[3]                      // 3 bytes
       } flds;
    } I2Cbuf;

If you totalize the size of each field (including the gaps due to alignment requirements), you get the total of 36 bytes.

[fredvr]

okay, I'm 100% convinced now..!!

float must be aligned on 4-byte boundary

This gave me enough to rearrange the struct in such way (all floats clustered at the start of the structs and in combination with __attribute__((packed)) that sizeof() now really reports 25bytes!!!!!

BINGO! Great to have learned about all this. I knew about allignment but never realized that this can have such an impact and you really have to be aware of this behaviour when all bytes count!!

thanks guys!

[Jarod42]

Anyway, it is unrelated to Codelite as this question is a code question.