QUESTION: strange behaviour of typedef enum and __attribute__((packed)) using sh-hms-g++ 3.0.3

Michael Svetlik m.svetlik@ssi-schaefer-peem.com
Wed Dec 11 01:02:00 GMT 2002



Fabio Giovagnini wrote:

>Hi everybody,
>that's my problem:
>if I define
>typedef struct ms{
>	unsigned long f1;
>	unsigned long f2;
>	unsigned char f3;
>	} __attribute__((packed)) ms_t;
>
>unsigned char test;
>
>...
>...
>test = sizeof(ms_t);
>...
>...
>
>i see test == 9;
>
>if I delete attribure specifier, i see test = 12.
>This is the expected behaviour !!!!
>
>If I define
>typedef enum en {em_f1 = 0, em_f2, em_f3} __attribute__(((packed),aligned(1))) 
>em_t;
>
>compiling with sh-hms-g++ 3.0.3 I have an error: missing semicolon ....
>instead compiling with sh-hms-gcc 3.0.3 everything works fine and the size is 
>the expected size.
>
>If I define
>typedef enum en {em_f1 = 0, em_f2, em_f3} em_t 
>__attribute__(((packed),aligned(1)));
>
>no compiler error I see with sh-hms-g++ but the size is 4 that's unexpected 
>size for this enum type if we suppose the __attribute__ keyword has been 
>working.
>
I tried to compile the above statement with i686-linux-gnu gcc 2.95.3, 
with g++ 2.95.3 and with g++ 3.1 - each of them from gnu.org, and each 
of them returned an error - you have a tricky compiler.
What's the sense of packing a singular, scalar data type ? Do you want 
to zip it :-?
What does your HITACHI do, when accessing a data type, bigger than one 
byte, on an even address (aligned(1)) ?
You dont expect a size of 4 for your enum - what's the sizeof(int) on 
your machine ?

>
>So I dedice the __attribute__ working in thuis sintax is not working, as 
>someone said some time ago.
>
>Does anyone have some tips to understand and solve this problem?
>
>Regards.
>
>
>------
>Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
>Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
>



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com



More information about the crossgcc mailing list