🚀 go-pugleaf

> While the gcc maintainers might consider this something to fix, it
> is not technically a bug, nor is the bitfield technically responsible
> for the problem.

Well, in general, I disagree... forcing alignment is one thing. Access
of aligned data should always adhere to the defined data type. But I'm
not the one writing the compiler :)

However, even if I did, I think this is separate bug:

  o The original example I supplied was over-simplified. If a
    'naturally' aligned structure is created, the problem still
    existis. See below.

  o If I force alignement (which I shouldn't have to do in the example
    below, the problem still exists. For protocol support this is a
    major problem. Yes, I know that structs defining protocol headers
    should never use bit-fields, but this is ported code. 

    And last, but far from least...

  o I think the example below actually loads data from the following
    fields!! 

In the end, I'll probably just ahve to bite the bullet and change the
code not to use bit-fields. However, I'd say that if this were a
problem with regualr chars too, most networking software would not
work.

Jeremy


/* behves the same without the aligned attributes
 */

struct  Bits
{
   /* if there's a bit field:
    */
   unsigned char y:4, x:4 __attribute__ ((aligned (1)));

   char pad __attribute__ ((aligned (1)));
   char pad2 __attribute__ ((aligned (1)));
   char pad3 __attribute__ ((aligned (1)));

   /* if the following is present, the above bit field does a int 
    * fetch... apparently through pad3! 
    */
   int possitiveAlignemnt __attribute__ ((aligned (1)));

} __attribute__ ((aligned (1)));


int main()
{
   char data[30];
   register struct Bits *bits;

   bits = &data[2];

   printf("%d\n", sizeof(struct Bits));

   /* I think the folling is loading through pad3!!!
    */    
   bits->y = 5;

   return 0;
}