Hi, I am just curious to know what the reason behind MISRA rule 111. The rule says - Bit fields shall only be defined to be one of type unsigned int or signed int I have used UINT32 instead of unsigned int in my code but compiler has thrown a warning says - "field type should be int" Could somebody please put light on this. Thanks Vikas --------------------------------------- Posted through http://www.EmbeddedRelated.com
Reason behind MISRA rule 111
Started by ●May 12, 2011
Reply by ●May 12, 20112011-05-12
On 05/12/2011 01:00 PM, vikasvds wrote:> Hi, > > I am just curious to know what the reason behind MISRA rule 111. > > The rule says - Bit fields shall only be defined to be one of type unsigned > int or signed int > > I have used UINT32 instead of unsigned int in my code but compiler has > thrown a warning says - "field type should be int" > > Could somebody please put light on this.According to C99: "A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type" Assuming UINT32 is implemented as 'unsigned long', it falls in the 'implementation-defined' category, which is not portable.
Reply by ●May 12, 20112011-05-12
On 12/05/2011 13:00, vikasvds wrote:> Hi, > > I am just curious to know what the reason behind MISRA rule 111. > > The rule says - Bit fields shall only be defined to be one of type unsigned > int or signed int > > I have used UINT32 instead of unsigned int in my code but compiler has > thrown a warning says - "field type should be int" > > Could somebody please put light on this. >"Unsigned int" and "signed int" are the only types that are guaranteed to be available by any C compiler. Other types typically work with most compilers, but may have different sizes or alignments on different targets or compilers. For example, if you use an enumerated type, one compiler may align it to 8-bit boundaries, whereas another might align it to "int" boundaries (16-bit or 32-bit). If you are careful to make sure your code is as portable as it needs to be, and that sizes and alignments are correct on your target, then I personally see no reason to follow this rule. Using specific types correctly is an important aspect of writing clear and correct code.
Reply by ●May 12, 20112011-05-12
On 5/12/2011 4:00 AM, vikasvds wrote:> Hi, > > I am just curious to know what the reason behind MISRA rule 111. > > The rule says - Bit fields shall only be defined to be one of type unsigned > int or signed int > > I have used UINT32 instead of unsigned int in my code but compiler has > thrown a warning says - "field type should be int" > > Could somebody please put light on this. > > Thanks > Vikas > > > > --------------------------------------- > Posted through http://www.EmbeddedRelated.comOn top of the reasons other people have posted, think about this for a bit. A bitfield already has a defined field length, given when you specify it. By declaring a UINT32, you're calling out a typedef that also has a defined field length. If the bitfield you're calling out is 32 bits long you're simply being redundant. If it's anything other than that, you're conflicting with yourself. In neither case has declaring the bitfield to be of type UINT32 provided you with any advantage. -- Rob Gaddi, Highland Technology Email address is currently out of order
Reply by ●May 12, 20112011-05-12
In message <4dcbbfb7$0$32470$e4fe514c@news.xs4all.nl>, Arlet Ottens <usenet+5@c-scape.nl> writes>On 05/12/2011 01:00 PM, vikasvds wrote: >> Hi, >> >> I am just curious to know what the reason behind MISRA rule 111. >> >> The rule says - Bit fields shall only be defined to be one of type unsigned >> int or signed int >> >> I have used UINT32 instead of unsigned int in my code but compiler has >> thrown a warning says - "field type should be int" >> >> Could somebody please put light on this. > >According to C99:Which is irrelevant. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●May 12, 20112011-05-12
In message <pL2dneKTAZlGIFbQnZ2dnUVZ_h-dnZ2d@giganews.com>, vikasvds <vikasetc@n_o_s_p_a_m.gmail.com> writes>Hi, > >I am just curious to know what the reason behind MISRA rule 111. > >The rule says - Bit fields shall only be defined to be one of type unsigned >int or signed int > >I have used UINT32 instead of unsigned int in my code but compiler has >thrown a warning says - "field type should be int" > >Could somebody please put light on this.Not here they can't. Try http://www.misra-c.com and go to the forum where you will get the definitive answer. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●May 12, 20112011-05-12
On 12/05/11 17:47, Rob Gaddi wrote:> On 5/12/2011 4:00 AM, vikasvds wrote: >> Hi, >> >> I am just curious to know what the reason behind MISRA rule 111. >> >> The rule says - Bit fields shall only be defined to be one of type >> unsigned >> int or signed int >> >> I have used UINT32 instead of unsigned int in my code but compiler has >> thrown a warning says - "field type should be int" >> >> Could somebody please put light on this. >> >> Thanks >> Vikas >> >> >> >> --------------------------------------- >> Posted through http://www.EmbeddedRelated.com > > On top of the reasons other people have posted, think about this for a > bit. A bitfield already has a defined field length, given when you > specify it. By declaring a UINT32, you're calling out a typedef that > also has a defined field length. > > If the bitfield you're calling out is 32 bits long you're simply being > redundant. If it's anything other than that, you're conflicting with > yourself. In neither case has declaring the bitfield to be of type > UINT32 provided you with any advantage. >That's not the whole story. When you pick a type for a bitfield, you give several things - one is the /maximum/ allowed bitlength (such as 32 bits in this case). Another is the alignment. For example, if you write "struct { uint8_t a : 2; uint32_t b : 4; } bits" then bits.a will be at the start of the structure, followed by padding to allow b to fit within the next 32-bit alignment block. You also affect the type of the extracted field - with the above structure on a 16-bit machine, "a" will be promoted to 16-bit int if you use it in arithmetic, while "b" will be promoted to 32-bit uint after extraction. And if you have declared the bitfield to be volatile (or its components as volatile), then the underlying type may have some effect on the instructions used to access the data. However, I don't think this is well defined by C, and compilers are not consistent. Bitfields have their uses, but you definitely want to check your compiler and what it is generating - don't expect them to be portable.
Reply by ●May 12, 20112011-05-12
On 12.05.2011 20:16, David Brown wrote:> That's not the whole story. When you pick a type for a bitfield, you > give several things - one is the /maximum/ allowed bitlength (such as > 32 bits in this case). > > Another is the alignment.No, it's not. Portable C code has _no_ control over alignment whatsoever, particularly not regarding bitfields.> For example, if you write "struct { uint8_t a : 2; uint32_t b : 4; } > bits" then bits.a will be at the start of the structure, followed by > padding to allow b to fit within the next 32-bit alignment block.No. Nothing in the language definition requires any padding in this case. That struct can perfectly legally fit into a single byte.> You also affect the type of the extracted field - with the above > structure on a 16-bit machine, "a" will be promoted to 16-bit int if > you use it in arithmetic, while "b" will be promoted to 32-bit uint > after extraction.Not necessarily, given that any compiler, including the one for that unspecifited "16-bit machine" may not even allow you to _compile_ that code, much less do what you think it should with it.> Bitfields have their uses, but you definitely want to check your > compilerActually from the point of view of MISRA C you have that backwards. The moment you use any information you needed to check your compiler manual for, you've left common ground, and made your code unportable.
Reply by ●May 12, 20112011-05-12
Hans-Bernhard Br=C3=B6ker wrote:> On 12.05.2011 20:16, David Brown wrote: > >> Bitfields have their uses, but you definitely want to check your >> compiler > > Actually from the point of view of MISRA C you have that backwards. Th=e> moment you use any information you needed to check your compiler manua=l> for, you've left common ground, and made your code unportable.Using bitfields and expecting a certain representation is unportable any= way, as the Endianess of bit-fields is implementation-defined. Vinzent. -- = A C program is like a fast dance on a newly waxed dance floor by people = carrying razors. -- Waldi Ravens
Reply by ●May 13, 20112011-05-13
On 05/13/2011 12:10 AM, Vinzent Hoefler wrote:> Hans-Bernhard Bröker wrote: > >> On 12.05.2011 20:16, David Brown wrote: >> >>> Bitfields have their uses, but you definitely want to check your >>> compiler >> >> Actually from the point of view of MISRA C you have that backwards. The >> moment you use any information you needed to check your compiler manual >> for, you've left common ground, and made your code unportable. > > Using bitfields and expecting a certain representation is unportable > anyway, as the Endianess of bit-fields is implementation-defined.A lot of stuff is implementation defined, such as representation of integers and floats. It doesn't have to be a problem, unless you move the binary representation from one implementation to another. If you use the bitfields only internally, there are no portability concerns.
