Lpc2000

Hi,

It makes a lot of sense what you are saying. What I was trying to do was 
moving bytes from a SD card into the structure.
The structure was made to follow the format of which the bytes was 
aligned on the SD card. I thought that this was a very beautiful way of 
doing it. I have seen code grabbing the struct byte by byte. However, 
when I ran this code on a HCS12 CPU then I could just make a memcpy into 
the struct and that was it. It was way more code size effective and much 
nicer to look at.

But I get your point about the portability! So there is two ways I can 
solve this problem... Right? Either give the compiler a pragma to pack 
the struct and live with the portability problems or rewrite my code to 
grab the protocol byte by byte.

Best regards
   Jan

brendanmurphy37 wrote:
>
> Hi,
>
> When you say "it's not possible to get the correct result from
> the uiBytesBeSector" is this something you've seen in practice, or
> just an assumption you're making?
>
> The language definition allows compilers to place fields within
> structures wherever they want. Typically, padding fields are added
> to ensure the allignment rules of the target processor are met. This
> is why it is dangerous to make any assumptions about how fields are
> actually stored in memory.
>
> If you're using such a struct to help define the structure of fields
> in memory (e.g. in data recived in a particular format on a
> communications link), it is non-portable. You can try and use some
> form of "packed" type modifier to try and sort this out, but this is
> also non-portable. The safest way around this is to read the data a
> byte at a time into your structure.
>
> In summary: if you declare the structure shown below, you shold have
> no problems, unless you're doing something that makes assumptions
> about how the fields are stored (e.g. type-casting a pointer to such
> a structure to a pointer to some other type or memory buffer).
>
> Brendan
>