Hi all! I am experiencing the following problem:
sizeof(EDA.stPARAM) returns 0x80 with CA.exe V2.41 which in my opinion is the correct result, but with CA.exe V2.50a it returns 0x82. Can somebody explain this behaviour to me? Code sample is included below:
file eda_st.inc:
struct {
byte ubFree_0000h[16] ;/* 000h-00Fh: */
byte ubFree_0010h[16] ;/* 010h-01Fh: */
byte ubFree_0020h[16] ;/* 020h-02Fh: */
byte ubFree_0030h[16] ;/* 030h-03Fh: */
byte ubFree_0040h[16] ;/* 040h-04Fh: */
byte ubFree_0050h[16] ;/* 050h-05Fh: */
byte ubFree_0060h[16] ;/* 060h-06Fh: */
byte ubFree_0070h[16] ;/* 070h-07Fh: */
}stPARAM;
byte VER_HWVers ;/* 000h: */
byte ubFree_0000h[127] ;/* 001h-07fh: */
}stABGLEICH;
---------------------- file eda_usr.h:
typedef struct {
#include "eda_st.inc" // struct mit Parametern
} EDA_sttyDAT;
extern EDA_sttyDAT EDA;
---------------------- file eda_usr.c:
#define TAR_RAMCOPY 0x40001000
EDA_sttyDAT EDA __at(TAR_RAMCOPY);// RAM-Kopie
Depending on where the structure is located in memory, the compiler/linker may decide to pad it to achieve word alignment.
Ok, I know that, but I guess this is not the problem. The struct is located at address 0x40001000 (see code sample). The struct members have a length of 128 bytes each so there should be no need for padding.
The struct members have a length of 128 bytes each
That's what you think. The compiler thinks otherwise.
The problem is one level deeper: it's in the original assumption that there is such a thing as a "correct" sizeof() figure for a C struct. There isn't. The size of a struct depends on things outside the source code.
I see this in a more practical way. The project was set up with V2.41 and everything worked fine. Then we switched to V2.50a and out of a sudden the sizeof expression doesn't work correctly anymore. I have checked the size of the EDA struct in the MAP file and it is exactly the size I would have expected. The sum of the sizeof over all struct members simply doesn't match the occupied memory space. The sum of the elements is by six bytes larger than the overall size. The original struct has three members and the sizeof expression evaluates to the expected size plus 2 Bytes for every member. I really think this is strange behaviour.
Maybe the compiler want to add an extra byte of empty data at end of struct, to make sure that it is allowed to do a 16-bit access to the last byte without overflowing into unknown data space.
But since 1 bytes of overflow protection makes the struct incorrectly aligned, the compiler then has to add more padding.
Never depend on a specific size of a data structure.
By the way, why are you plaing with include files when defining your struct? It doesn't help readability.
I just noticed that I used an old MAP file. The size of the EDA struct DOES match the sum of the sizeof values. But I still don't understand why there is a different behaviour in compiler version 2.51a in comparison to version 2.41. Thanks to all for your advice.
View all questions in Keil forum