回复: PR 1098: "struct ipovly" not packed.

[Denny.Bai]

Firstly, maybe one of the problems is struct aligned restriction.
when gcc compile the source file, the option "
-mstructure-size-boundary=32" is used.  so no matter how  the struct
is declared, the sizeof the struct will be a multiple of 4.

for example:

struct	ether_header {
	u_char	ether_dhost[ETHER_ADDR_LEN];
	u_char	ether_shost[ETHER_ADDR_LEN];
	u_short	ether_type;
};


the ETHER_ADDR_LEN is 6, and size of  u_short is 2, so the real size
of this struct  is 6 + 6 + 2 = 14. but in fact the size of the struct
is 16.  when  code requires the space of the ether_header,   system
will give it more space than it needs.  and the data aligned will be
like this:

ether_dhost takes 6 bytes ,  followed by  ether_shost taking 6 bytes,
and then 2 blank bytes, the last is ether_type which takes 2 bytes.
so the total size of ether_header is 16.

 if  wrong ether_header wrapped in net packed is sent,  destination
will not recognize real meaning of  data received.


secondly, if the option "packed" is added, another problem will follow
by casting types from structs which owns "packed"  to  ones which not
owned.   convert casting pointers to different types  will also bring
violating alignment restrictions. the following sentences is
excerpted from <<C: a Reference Manual>>

  C does give the programmer the ability to violate alignment
restrictions by casting pointers to different types.  ......... If the
alignment requirement for a type S is less stringent than that for
type D, then the conversion from a "pointer to types S"  to a "pointer
to type D" could result in either of two kinds of unexpected behavior.
 Firts, an attempt to use the reulting pointer to fetch or store an
object of type D may cause an error, halting the program. Second,
either the hardware or the implementation may "adjust" the destination
pointer to be valid, usually by forcing ti back to the nearest
previous valid address.

-- 
Bai.Shaolin
Northeastern  University, ShenYang,China