Rule 3.5: bitfields and basic types

6.3 Documentation

Moderators: misra-c, david ward

Locked
Reggi
Posts: 2
Joined: Thu Feb 15, 2007 9:41 am
Location: Germany - Lippstadt

Rule 3.5: bitfields and basic types

Post by Reggi » Fri Jan 25, 2008 10:00 am

Hi,

i have a question about the type in bitfields.

In the example in rule 3.5 there is the note \"Note: use of basic types is required\"

In rule 6.3 it says: \"typedefs are not considered necessary in the specification of bit-field types.\"

So typedefs are not forbidden for bitfields.

I don't anderstand the stätement in the example of rule 3.5.

Why are basic types required here?

Do you have an explanation, why i should write

unsigned int x_set:1

and not

uint32_t ? x_set:1?

Thanks,
Regine

Lundin
Posts: 70
Joined: Mon Dec 10, 2007 1:57 pm

Post by Lundin » Thu Jan 31, 2008 9:51 am

ISO C states that the only valid type for bitsets is int, unsigned int and signed int. Using char or long is implementation-defined behavior. And if you use uint32_t, you are most likely using \"typedef unsigned long uint32_t\", and unsigned long in bit-fields isn't covered by ISO C.

---

My personal opinion of the best way to comform with the bit-field rules is to forbid the usage of bit-fields entirely for your applications. Bit-fields are poorly defined by the standard and have plenty of various undefined- and implementation-defined behavior, making them a big hazard for the safety of the program. And they are completely redundant: you don't need to use them as the bitwise operators do the very same thing: they work on a byte level theoretically, but a good compiler translates bitwise operations to bit-level instructions, making bit-fields pointless.

Reggi
Posts: 2
Joined: Thu Feb 15, 2007 9:41 am
Location: Germany - Lippstadt

Rule 3.5: bitfields and basic types

Post by Reggi » Thu Jan 31, 2008 10:30 am

Hi,

sorry, the information in my post was insufficient.

Do you have an explanation, why i should write

unsigned int x_set:1

and not

uint32_t x_set:1? When uint32_t is a typedef unsigned int uint32_t; on a 32 bit architecture,
or
uint16_t x_set:1 When uint16_t is a typedef unsigned int uint16_t on a 16 bit architecture ??

It's no question that long and char are surely not allowed to use.

Thanks in advance.

Regine

sparker
Posts: 13
Joined: Thu Apr 28, 2005 2:05 pm
Location: Cambrige, UK

Re: Rule 3.5: bitfields and basic types

Post by sparker » Fri Feb 01, 2008 9:12 am

Reggi wrote: why i should write

unsigned int x_set:1

and not

uint32_t x_set:1? When uint32_t is a typedef unsigned int uint32_t; on a 32 bit architecture,
or
uint16_t x_set:1 When uint16_t is a typedef unsigned int uint16_t on a 16 bit architecture ??
What would the purpose of this be? The point of the "sized types" is that they offer some measure of platform portability. Here you are using them to decrease portability -- you'll need to ensure that your bit-field is declared with the type that matches int on your platform. If you want an unsigned bit field then "unsigned" is the word to use.

stephen

misra-c
Posts: 569
Joined: Thu Jan 05, 2006 1:11 pm

Re: Rule 3.5: bitfields and basic types

Post by misra-c » Wed May 21, 2008 2:15 pm

The MISRA-C team concur with the previous posting by sparker.
---
Posted by and on behalf of
the MISRA C Working Group

Locked

Return to “6.3 Documentation”