DPRG List  

[DPRG] I didn't want this to work: C structure confusion

Subject: [DPRG] I didn't want this to work: C structure confusion
From: Clem Taylor clem.taylor at gmail.com
Date: Fri Sep 8 13:30:42 CDT 2006

On 9/8/06, Dale Wheat <dale at dalewheat.com> wrote:
> typedef enum { GPIO0_0, TXD0, MAT3_1 } PCB0_0;
> typedef enum { GPIO0_1, RXD0, MAT3_2 } PCB0_1;
> This also works.  I repeat this process many times and define all the
> possible combinations of pin select options for the available port pins,
> or should I say I will do this once I get it all working, but this
> should be enough to test it for now.
> Now I want to gather all these bit patterns together in the same order
> that they are present in the actual hardware register.  I use the C
> aggregate data typing feature, struct, and limit the size of each
> bitfield to two, like this:
> volatile struct PINSEL0_T {
>         PCB0_0 p0_0 : 2;
>         PCB0_1 P0_1 : 2;
> } *PINSEL0 = (struct PINSEL0_T *) 0xE002C000;

> PINSEL0->p0_0 = GPIO0_0;
> PINSEL0->p0_1 = GPIO0_0; // <-- not supposed to be legal!

Wow, gcc is really letting you down. I never thought to use enums like
this, but I use bitfields with hardware all the time. Some additional
type checking would be really nice here. I would have thought that
this would have generated a warning, but when I tried it I didn't get
a warning either (gcc 4.0 and 4.1 with -Wall and -Wextra). It also
doesn't seem to complain about assigning something from one enum to
another which I thought would also generate a warning. gcc will
generated nifty warnings when using enums in a switch that will
complain about missing cases.

FYI, I'd be concerned about using bit fields and enums because of
packing and register size issues. I always tend to use uint32_t or
uint16_t with bitfields and make sure that all the bit fields add up
to the size of the storage class. This helps to make sure that I get
the expected behavior.

                             Not much help,

More information about the DPRG mailing list