Page 1 of 1

Boolean typedef and rules 6.4 and 10.1

Posted: Thu Nov 10, 2011 3:09 pm
by rhbarnes
Hi, I need some advice regarding typedef and boolean types; we use the following typedefs in a common 'types' header file (I have only included the relevant ones here):

typedef unsigned int uint16_t;
typedef unsigned int bool_t;
#define FALSE ((bool_t)0U)
#define TRUE ((bool_t)1U)

If we create a structure containing a bit-field, for example..

typedef struct
{ // Structure used to pass software/hardware info to the system
i8pc_string_t i8pc_software_version; // Software version number
i8pc_string_t i8pc_serial_number; // Serial number
bool_t bl_hardware_supported:1; // Hardware revision is supported
} st_software_info_t;

and then modify the boolean member as such...

sts_sw_info.bl_hardware_supported = FALSE;

then this is ok, however when we test the value as such...

if (sts_sw_info.bl_hardware_supported == FALSE)
{
// Do something...
}

then we violate rule #10.1. Is this due to the underlying type expected by the if statement?

In addition, if any bit-field is defined using a typdef'd type (e.g. uint16_t u4_my_bits:4;), then we violate rule 6.4; why is this since uint16_t has been typedef'd as unsigned int?

Any help appreciated,

Regards
Richard

Re: Boolean typedef and rules 6.4 and 10.1

Posted: Tue Nov 15, 2011 8:51 pm
by misra-c
In both code fragments

Code: Select all

sts_sw_info.bl_hardware_supported = FALSE;
and

Code: Select all

if (sts_sw_info.bl_hardware_supported == FALSE)
{
// Do something...
}
the underlying types of the operands are unsigned int. The fact that the controlling expression of the if statement is expected to be Boolean does not affect anything.

It would seem that your tool is diagnosing a violation of Rule 10.1 when there isn't any problem.

Regarding Rule 6.4, it doesn't matter whether unsigned int is used or whether another type that is defined as unsigned int is used. The two are equivalent, as noted in the code for Rule 6.4 in the MISRA C exemplar suite.

If this is being reported as a Rule 6.4 violation by a tool then, again, it would appear that the tool is diagnosing a violation when there is no actual problem.