<![CDATA[MISRA Discussion Forums - 6.6 Types]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 19:06:25 +0000 MyBB <![CDATA[10.1 violated]]> https://forum.misra.org.uk/showthread.php?tid=1194 Wed, 08 Jul 2015 05:34:34 +0000 minnu]]> https://forum.misra.org.uk/showthread.php?tid=1194 9u
#define NUM2 8


/* gus32cmd is keyboard entry .numbers from 1 to 10*/

scanf("%d", &gus32cmd );

Switch(gus32cmd)
{
case:NUM
....
....
break;


case NUM2
..
..
break;

}

At lines case:NUM and case NUM2 I got following misra c error

"Rule 10.1 violated "implicit conversion of complex integer expression to a small sized integer is not allowed"
What correction I should do to avoid this error]]> 9u
#define NUM2 8


/* gus32cmd is keyboard entry .numbers from 1 to 10*/

scanf("%d", &gus32cmd );

Switch(gus32cmd)
{
case:NUM
....
....
break;


case NUM2
..
..
break;

}

At lines case:NUM and case NUM2 I got following misra c error

"Rule 10.1 violated "implicit conversion of complex integer expression to a small sized integer is not allowed"
What correction I should do to avoid this error]]> <![CDATA[Clarification for Rule 6.1]]> https://forum.misra.org.uk/showthread.php?tid=1172 Mon, 06 Apr 2015 09:02:40 +0000 anuj1085]]> https://forum.misra.org.uk/showthread.php?tid=1172
C standards says single character constant for eg. 'X' are int not char. So the following code:

char x = 'A';

is a violation of the rule as in this char x is storing a constant whose type is "int". If this is not the violation then how to interpret this rule as the all single character constants are int according to "c" standards.]]>
C standards says single character constant for eg. 'X' are int not char. So the following code:

char x = 'A';

is a violation of the rule as in this char x is storing a constant whose type is "int". If this is not the violation then how to interpret this rule as the all single character constants are int according to "c" standards.]]> <![CDATA[MISRA 6.1 with enum]]> https://forum.misra.org.uk/showthread.php?tid=1055 Mon, 12 May 2014 08:51:18 +0000 ziomocci]]> https://forum.misra.org.uk/showthread.php?tid=1055
I am encountering some problems trying to make MISRA 6.1 compliant my source code,
expecially using enumeration.

From one side, in the header file I declare:
typedef enum { FALLING_EDGE = 0x0, RISING_EDGE } t_EdgePolarity;

and from the other side, in the code I declare:
emios_error_t EMIOS_PIN_Config(t_PIO_CHANNELS _channel,
t_BusSelect _bsl,
t_EdgeSelection _edgesel,
t_EdgePolarity _edgepol,
t_ActiveFilter _filter)
{
... ... ... ... ... ...
/* Do somthing */
switch (_edgepol)
case FALLING_EDGE:
/* Do somthing */
break;
case RISING_EDGE:
/* Do somthing */
break;
default:
/* Do somthing */
break;
... ... ... ... ...
}
At compile time, green hills 5.1.6 compiler gives back this error message:
MISRA 2004 Rule 6.1:
only assignment and equality operators may be used on plain char
operand
switch (_edgepol)
^
It is only an example, but I have same error with all the enumeration used in
the code.

Any suggestions?

Thank you in advance,

Andrea Mocci, embedded SW developer @ Akhela s.r.l.]]>
I am encountering some problems trying to make MISRA 6.1 compliant my source code,
expecially using enumeration.

From one side, in the header file I declare:
typedef enum { FALLING_EDGE = 0x0, RISING_EDGE } t_EdgePolarity;

and from the other side, in the code I declare:
emios_error_t EMIOS_PIN_Config(t_PIO_CHANNELS _channel,
t_BusSelect _bsl,
t_EdgeSelection _edgesel,
t_EdgePolarity _edgepol,
t_ActiveFilter _filter)
{
... ... ... ... ... ...
/* Do somthing */
switch (_edgepol)
case FALLING_EDGE:
/* Do somthing */
break;
case RISING_EDGE:
/* Do somthing */
break;
default:
/* Do somthing */
break;
... ... ... ... ...
}
At compile time, green hills 5.1.6 compiler gives back this error message:
MISRA 2004 Rule 6.1:
only assignment and equality operators may be used on plain char
operand
switch (_edgepol)
^
It is only an example, but I have same error with all the enumeration used in
the code.

Any suggestions?

Thank you in advance,

Andrea Mocci, embedded SW developer @ Akhela s.r.l.]]> <![CDATA[6.2 and switch/case labels]]> https://forum.misra.org.uk/showthread.php?tid=1039 Tue, 11 Mar 2014 16:44:04 +0000 dreser]]> https://forum.misra.org.uk/showthread.php?tid=1039
Example:

Code:
const uint8_t CONSTANT_ONE = 12U;
const uint8_t CONSTANT_TWO = 34U;

uint8_t value = foo();

switch (value)
{
case CONSTANT_ONE:
  [...]
   break;
case CONSTANT_TWO:
  [...]
   break;
default:
  [...]
   break;
}

For each of the "case " lines PC-lint (from V9.00j on) complains about a "Disallowed use of non-numeric value in a case label".
I would have considered defining and using the contants as "storage and use of numeric values" as described in 6.2.
I also can not find a similar limitation in MISRA-C 2012. Though I might not have looked deeply enough as I only have it in printed form.

Thanks for any feedback you might have on this.]]>
Example:

Code:
const uint8_t CONSTANT_ONE = 12U;
const uint8_t CONSTANT_TWO = 34U;

uint8_t value = foo();

switch (value)
{
case CONSTANT_ONE:
  [...]
   break;
case CONSTANT_TWO:
  [...]
   break;
default:
  [...]
   break;
}

For each of the "case " lines PC-lint (from V9.00j on) complains about a "Disallowed use of non-numeric value in a case label".
I would have considered defining and using the contants as "storage and use of numeric values" as described in 6.2.
I also can not find a similar limitation in MISRA-C 2012. Though I might not have looked deeply enough as I only have it in printed form.

Thanks for any feedback you might have on this.]]> <![CDATA[Boolean typedef and rules 6.4 and 10.1]]> https://forum.misra.org.uk/showthread.php?tid=862 Thu, 10 Nov 2011 15:09:06 +0000 rhbarnes]]> https://forum.misra.org.uk/showthread.php?tid=862
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:4Wink, then we violate rule 6.4; why is this since uint16_t has been typedef'd as unsigned int?

Any help appreciated,

Regards
Richard]]>
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:4Wink, then we violate rule 6.4; why is this since uint16_t has been typedef'd as unsigned int?

Any help appreciated,

Regards
Richard]]> <![CDATA[6.2 With Respect to Arrays and Pointers?]]> https://forum.misra.org.uk/showthread.php?tid=762 Thu, 29 Jul 2010 15:23:34 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=762
Code:
signed char a[10] = {"123456789"};
signed char *b = "123456789";
]]>
Code:
signed char a[10] = {"123456789"};
signed char *b = "123456789";
]]> <![CDATA[6.4 and 6.5 with respect to unnamed bit fields?]]> https://forum.misra.org.uk/showthread.php?tid=731 Tue, 27 Apr 2010 16:24:08 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=731 <![CDATA[Do enumerators count as "numeric values"?]]> https://forum.misra.org.uk/showthread.php?tid=724 Thu, 25 Mar 2010 13:04:06 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=724 Quote:Numeric values/data are numbers such as 0, 5, 23, \x10, -3. ]]> Quote:Numeric values/data are numbers such as 0, 5, 23, \x10, -3. ]]> <![CDATA[Mixing plain char and non-plain char within ?:]]> https://forum.misra.org.uk/showthread.php?tid=723 Wed, 24 Mar 2010 14:03:26 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=723 Quote:[T]he second and third operands of the ternary conditional operator may both be of plain char type. Do these rules permit one of these two operands to have plain char type and the other to have signed char or unsigned char type?

For that matter, what about the mixing of such operands with operators considered acceptable for use with objects of plain char type? For example, do the rules permit the following:
Code:
void function( char a, signed char b )
    {
    if( a == b )
        { /*  do something  */ }
    }
?]]> Quote:[T]he second and third operands of the ternary conditional operator may both be of plain char type. Do these rules permit one of these two operands to have plain char type and the other to have signed char or unsigned char type?

For that matter, what about the mixing of such operands with operators considered acceptable for use with objects of plain char type? For example, do the rules permit the following:
Code:
void function( char a, signed char b )
    {
    if( a == b )
        { /*  do something  */ }
    }
?]]> <![CDATA[Plain chars within structs?]]> https://forum.misra.org.uk/showthread.php?tid=720 Thu, 18 Mar 2010 15:53:57 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=720
Quote:The permissible operators on plain char types are the simple assignment operator (=), equality operators (==, !=) and explicit casts to integral types. Additionally, the second and third operands of the ternary conditional operator may both be of plain char type.
What about the '.' operator? Or the '->' operator? Could not an object of structure type contain a plain char member, making that member the second operand of the operator?

What about bit addressing or sizeof?]]>
Quote:The permissible operators on plain char types are the simple assignment operator (=), equality operators (==, !=) and explicit casts to integral types. Additionally, the second and third operands of the ternary conditional operator may both be of plain char type.
What about the '.' operator? Or the '->' operator? Could not an object of structure type contain a plain char member, making that member the second operand of the operator?

What about bit addressing or sizeof?]]> <![CDATA[6.1, 6.2 and casts?]]> https://forum.misra.org.uk/showthread.php?tid=719 Thu, 18 Mar 2010 14:31:11 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=719 Does rule 6.2 permit a character value to be cast to signed/unsigned char type and then assigned to an object of signed/unsigned char?]]> Does rule 6.2 permit a character value to be cast to signed/unsigned char type and then assigned to an object of signed/unsigned char?]]> <![CDATA[Bitfields vs masks for SFRs]]> https://forum.misra.org.uk/showthread.php?tid=624 Wed, 11 Feb 2009 16:51:28 +0000 TheDoctor]]> https://forum.misra.org.uk/showthread.php?tid=624
Notwithstanding rule 18.4, on a micro I am working with at present the compiler writer provides access in the header file to each SFR through a union which overlays both a bitfield structure for the SFR and an unsigned object covering the whole width of the SFR. So if I want to extract (say) a 12-bit A/D value from an SFR location that contains the result as well as some other info e.g. status bits I can access this either as ADCchan.B.RESULT (where RESULT is a bitfield 12 bits wide) or ADCchan.U & 0x00000fffU.]]>
Notwithstanding rule 18.4, on a micro I am working with at present the compiler writer provides access in the header file to each SFR through a union which overlays both a bitfield structure for the SFR and an unsigned object covering the whole width of the SFR. So if I want to extract (say) a 12-bit A/D value from an SFR location that contains the result as well as some other info e.g. status bits I can access this either as ADCchan.B.RESULT (where RESULT is a bitfield 12 bits wide) or ADCchan.U & 0x00000fffU.]]> <![CDATA[int main() and rule 6.3]]> https://forum.misra.org.uk/showthread.php?tid=539 Mon, 23 Jun 2008 13:23:02 +0000 Lundin]]> https://forum.misra.org.uk/showthread.php?tid=539 Because if we state the width and signedness of main() we will suddenly make the app implementation-dependant and non-portable.

Also, ISO C strictly states that the return type shall be "int" on a hosted environment. One could interpret that as "it must be the primitive
data type int and no custom typedef".]]> Because if we state the width and signedness of main() we will suddenly make the app implementation-dependant and non-portable.

Also, ISO C strictly states that the return type shall be "int" on a hosted environment. One could interpret that as "it must be the primitive
data type int and no custom typedef".]]> <![CDATA[Rule 6.5 and unnamed 0-length bit field]]> https://forum.misra.org.uk/showthread.php?tid=439 Tue, 08 Jan 2008 14:44:47 +0000 pkruk]]> https://forum.misra.org.uk/showthread.php?tid=439
Code:
struct s {
    signed int : 0;        /* Is Rule 6.5 violated? */
  };

Rule 6.5 explicitly says that \"Bit fields of type signed int shall be at least 2 bits long.\" (or \"Bit fields of signed type shall be at least 2 bits long.\" in TC1).

This bit field is clearly smaller than 2 bits, but it serves other purpose than \"normal\" positive-size bit fields.

Should the code be changed to use \"unsigned int\" type (the rule would not apply), or is the 0-size bit field an exception to this rule?]]>
Code:
struct s {
    signed int : 0;        /* Is Rule 6.5 violated? */
  };

Rule 6.5 explicitly says that \"Bit fields of type signed int shall be at least 2 bits long.\" (or \"Bit fields of signed type shall be at least 2 bits long.\" in TC1).

This bit field is clearly smaller than 2 bits, but it serves other purpose than \"normal\" positive-size bit fields.

Should the code be changed to use \"unsigned int\" type (the rule would not apply), or is the 0-size bit field an exception to this rule?]]> <![CDATA[Boolean Types]]> https://forum.misra.org.uk/showthread.php?tid=338 Mon, 05 Feb 2007 19:08:23 +0000 djtachyon]]> https://forum.misra.org.uk/showthread.php?tid=338
Some thoughts:

typedef unsigned char boolean_t
#define TRUE (0==0)
#define FALSE (!0)

Thanks.]]>
Some thoughts:

typedef unsigned char boolean_t
#define TRUE (0==0)
#define FALSE (!0)

Thanks.]]>