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