[U-Boot] IP_t should be a "packed" struct

[Wolfgang Denk]

Dear Luigi Mantellini,

In message <b73e93990901281504k3940b356nbff298e137c0e707 at mail.gmail.com> you wrote:
> 
> > We (i. e. all of us except you) do not have a problem.
> 
> my question is: how can you be sure on this? I haven't used strange

Because I read the documentation?

> compilers or strange CFLAGS.. I just do "make" on a supported target
> (qemu_mips).
> I haven't any problem to correct my local source tree. I ask myself
> why gcc offers a packed atribute, ms-vc offers pragma packed, ...

There are cases where it makes a difference. Assume someting like
this:

struct foo {	/* offset     normal	packed	*/
	long	l;	/*	0	    0	*/
	char	c;	/*	4	    4	*/
	long	x;	/*	8	    5	*/
};

Here the alignment requirements are 4 byte for "l", 1 byte  for  "c",
and  4  byte for "x". The compiler will align all variables on 4 byte
addresses normaly, i. e. the offsets are 0, 4 and 8. With  ""packed",
the  natural alignment of "x" on a 4 byte border will be ignored, and
instead it will be "packed" immediately following the storage for the
"c" variable, i. e. resulting in offset  5.  This  may  easily  cause
problems  on some architectures, but that's what you get when you ask
for it.

Now study the data structures used  for  netwrking  -  they  are  all
carefully  crafted that the natural aligment "just fits", i. e. there
are no gaps between variables if they are aligned naturally.

Your compiler must be doing really stupid things here.

> the behavior is clear: in my environment, the default choice is to
> align fields on 32bit for speed reasons... and I like this by default
> for my applications.

What makes you think it would be faster if a 16 bit ("short") data
type was no aligned on a 32 bit border, but only on a 16 bit one?
I am not aware of a system where that would make any speed difference. 

Same for 8 bit (char) data types - for these,  alignment  at  32  bit
offsets makes zero sense to me.

> I can ignore the problem using options like -Os (I will try tomorrow)
> or -fpack-struct or other global mechanisms or, pay attention on
> structures definitions to be sure that the structure size is compiler
> and cflags independent.

The currentcode has no such problems, standard conforming compilers
assumed.

> I see. I would like to understand why this structure is
> optimization-prof. I will study tomorrow...

Please read the docs.

> iso C doensn't require packing by default of the structures. To assume

We are not talking about "packing" here. We are  just  talking  about
alignment  and  insertion of gaps to ensure natural alignment of data
types. This is a well documented area.

> that a structure is packed by default is not a good assumption. All

This is NOT packing! Please do not mix unrelated terms.

> which documentation should I read? iso c documents? gcc manuals? I

ISO C or GCC, whatever is more handy.

> Anyway,  I don't want to talk about philosophy. I just noticed an
> anomaly and I wanted to share with the ML.

Sorry, but there is no anomaly. This is normal, (mostly) standard
conforming C code.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"When anyone says `theoretically,' they really mean `not really.'"
- David Parnas