Problems using uint_16 in a structure

[mykepredko]

Hey Folks,

I'm having a problem specifying a 16 bit field in a structure.  When I declare:

typedef struct myfiles_def_struct {

    // Block Header

    uint_16 FHDR;

    // Size of data Block

    uint_32 FSIZE;

    // 8 Character Block Identifier

    uint_8 FNAME[8];

    // Block Data/size specified by “FSIZE” 

    uint_8 FDATA[]; 

} MYFILES_DEF_STRUCT, _PTR_ MYFILES_DEF_STRUCT_PTR;

the offset for "FSIZE" is 4 from "FHDR" and not 2 like I would expect. 

I've searched the CW as well as the MQX forums for people who have found similar issues but with no luck. 

Any ideas?  I feel like I'm missing something incredibly basic here. 

Thanx,

myke

[CompilerGuru · Accepted solution]

It's the uint_32 FSIZE field which gets aligned to its natural boundary. I usually try to align every field to its natural aligment to avoid compiler issues like this one. Probably there is a compiler pragma to control the alignment, if really necessary. Be careful to end the pragma's effect.

Is it strictly required that FSIZE starts at offset 2? One alternative would also be to splitup FSIZE into 2 separate uint_16's.

Daniel

[mykepredko]

Hi Daniel,

Thank you for the comments. 

Unfortunately, the data in this structure is being provided by another system and, along with this, there will be quite a few of these structures which is why the header was reduced to 16 bits and not 32 bits in the first place because the extra two bytes in each structure will become quite substantial. 

There may be an opportunity to reverse FHDR and FSIZE when the data is generated for the ColdFire - this will mean that the data between the two systems will be no longer be the same (which could make for problems down the road). 

I'm hoping to hear from the FSL guys regarding the boundaries and seeing if there is any opportunity there. 

That's an interesting idea about breaking up the 32bit size field into two 16 bit - I'll try it and see how it works out.  In this case, I would be doing manually what the compiler should be doing automatically. 

Thanx,

myke

[mykepredko]

Hey Daniel,

I just converted the 32bit FSIZE to a 16bit FSIZEHIGH and 16bit FSIZELOW.  The structure comes out as 14 bytes in size (which is correct) and the offsets are correct.  I could probably clean things up a bit more by making these two 16 bit values into a 32 bit union (I don't know if I'm that energetic right now). 

I'm still interested in hearing what FSL comes back with regarding the original structure and if there is anything that they can suggest to allow its use.

Thanx again for the suggestion,

myke

[CompilerGuru]

I fear the union approach won't help because as soon as the union contains a long, the compiler will start to insert the align bytes as before.

The basic problem is that for your given layout the 4 byte int is not aligned for its type. Most 32 bit architecture compilers I'm aware of (not just CF) do align such a field by default. With a CF (and x86, for example) I'm sure there is a pragma to give you the desired layout. I guess something along the lines of a #pragma align (not sure).

Anyway, there are other architectures like PPC which won't allow the unaligned long.

So if you only want to support CF, search the pragma in the manual. If it matters to keep the code clean and easy to port for other architectures in the future I would go with the 2 byte only fields (or to explicitly fix the alignment with an additional 2 byte filler for all). That way you can keep the code clean and avoid CF specifics.

Daniel

[mykepredko]

Hi Daniel,

I've come to the same conclusion as well.  The code isn't too ugly although it should probably be implemented using a macro.

I don't see the same behaviour with gcc (which is the compiler used to generate these structures in the first place on a WinPC), but its operation might be tailored to allow this. 

Thanx for the suggestion - things are moving forwards because if.

myke

[mykepredko]

Sorry, I should have noted that "sizeof(MYFILES_DEF_STRUCT)" returns 16 and not 14 as expected.

Thanx,

myke