Hello,
Jani Monoses wrote:
Why would they be put on 4 byte boundaries? The natural boundary of
u16s is 2 bytes, not 4 bytes. Putting a u16 on a 4 byte boundary
>>changes
nothing.
for more efficient access on platforms which access 32 bit aligned
values faster then if they were nonaligned (this requiring two bus
cycles)
>
But Timmy talking about 16 bit values.
At least the ARM compiler will align these on 16-bit boundaries (i.e.
all byte-addresses that have their least significant bit zero)
You don't really think that people added packing directives to
compilers and that we use it from lwip to confuse others do you :)
Jani, you mentioned that GCC in combination with ARM will generate
fields that have greater-than-natural alignments (if I intepreted
correctly).
This piece of code should show the actual alignments under GCC:
#include <stdio.h>
#include <stddef.h>
struct foo {
char a;
char b
short c;
/* uncomment to test for packet struct *?
} /*__attribute__ ((packed))*/ ;
#define OFFSET_A offsetof(struct foo, a)
#define OFFSET_B offsetof(struct foo, b)
#define OFFSET_C offsetof(struct foo, c)
int main ()
{
printf (“offset A = %d\n”, OFFSET_A);
printf (“offset B = %d\n”, OFFSET_B);
printf (“offset C = %d\n”, OFFSET_C);
return 0;
}
What I expect as output in both the non-packed and packed case is this:
offset A = 0
offset B = 1
offset C = 2
If however, the compiler comes up with this in the non-packed case:
offset A = 0
offset B = 1
offset C = 4
then there is greater-than-natural alignment, and holes exists in the
protocol headers.
Regards,
Leon.