<![CDATA[MISRA Discussion Forums - 6.12 Expressions]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 15:13:28 +0000 MyBB <![CDATA[Recommendations to resolve issue 12.4]]> https://forum.misra.org.uk/showthread.php?tid=1158 Wed, 25 Feb 2015 22:16:57 +0000 jbrookley]]> https://forum.misra.org.uk/showthread.php?tid=1158
I had a question regarding rule 12.4 and realize I asked a similar question here:

http://www.misra-c.com/forum/viewtopic.php?f=68&t=1296

I didn't want to bump an old thread so I started a new one (hopefully, that's ok).

I received an error for rule 12-4 with the following section of code:

Code:
if((CommandState!=7u)&&(CommandState!=8u)&&(CommandState!=9u)&&(CommandState!=10u)&&(CommandState!=11u)&&(commData==0x24u)) /* Please ignore the fact this is written inefficiently for now */
{
        CommandState = 0u;
}

I resolved this issue using the following section of code but I wasn't sure if this is the best way to handle the code or if it's recommended to handle it using a different technique:

[code]if(commData==0x24u)
{
if(CommandState>=7u)
{
if(CommandState]]>
I had a question regarding rule 12.4 and realize I asked a similar question here:

http://www.misra-c.com/forum/viewtopic.php?f=68&t=1296

I didn't want to bump an old thread so I started a new one (hopefully, that's ok).

I received an error for rule 12-4 with the following section of code:

Code:
if((CommandState!=7u)&&(CommandState!=8u)&&(CommandState!=9u)&&(CommandState!=10u)&&(CommandState!=11u)&&(commData==0x24u)) /* Please ignore the fact this is written inefficiently for now */
{
        CommandState = 0u;
}

I resolved this issue using the following section of code but I wasn't sure if this is the best way to handle the code or if it's recommended to handle it using a different technique:

[code]if(commData==0x24u)
{
if(CommandState>=7u)
{
if(CommandState]]> <![CDATA[Is it possible to right shift a signed variable? (12.7)]]> https://forum.misra.org.uk/showthread.php?tid=994 Tue, 29 Oct 2013 18:01:17 +0000 jbrookley]]> https://forum.misra.org.uk/showthread.php?tid=994
I have an application that I need to right shift a signed variable but it seems to be giving me some issues. My initial line was:

Code:
typedef unsigned char uchar8;
typedef signed long slong32;

slong32 Shifted Long;
uchar8 NumBitsShift;

ShiftedLong >>= NumBitsShift - 1u;

Due to various MISRA C requirements, the code has morphed into this ridiculous block:

Code:
typedef unsigned char uchar8;
typedef signed char schar8;
typedef signed long slong32;

slong32 Shifted Long;
uchar8 NumBitsShift;
uchar8 tempchar = 0;
slong32 templong = 0;

tempchar = (uchar8)(NumBitsShift - 1u);

if((tempchar>=1u)&&(tempchar> tempchar; /* MISRA C 12.7 Error here */
}

On the flagged line, I get the error "Underlying type of LHS operand bitwise operator is signed type: ShiftedLong". I've tried fixing that by casting the tempchar as shown below:

Code:
ShiftedLong = ShiftedLong >> (slong32)tempchar;

I even tried to go completely over the top with plans to scale it back once I isolate the problem by doing this:

Code:
ShiftedLong = (slong32)((slong32)ShiftedLong >> (slong32)tempchar);

It appears, I am still having the same problem. What it now appears, based on this, is that it is not possible to right shift a signed variable. Is this true or is there a way around this?

Any help you can give me would be appreciated. Thanks!]]>
I have an application that I need to right shift a signed variable but it seems to be giving me some issues. My initial line was:

Code:
typedef unsigned char uchar8;
typedef signed long slong32;

slong32 Shifted Long;
uchar8 NumBitsShift;

ShiftedLong >>= NumBitsShift - 1u;

Due to various MISRA C requirements, the code has morphed into this ridiculous block:

Code:
typedef unsigned char uchar8;
typedef signed char schar8;
typedef signed long slong32;

slong32 Shifted Long;
uchar8 NumBitsShift;
uchar8 tempchar = 0;
slong32 templong = 0;

tempchar = (uchar8)(NumBitsShift - 1u);

if((tempchar>=1u)&&(tempchar> tempchar; /* MISRA C 12.7 Error here */
}

On the flagged line, I get the error "Underlying type of LHS operand bitwise operator is signed type: ShiftedLong". I've tried fixing that by casting the tempchar as shown below:

Code:
ShiftedLong = ShiftedLong >> (slong32)tempchar;

I even tried to go completely over the top with plans to scale it back once I isolate the problem by doing this:

Code:
ShiftedLong = (slong32)((slong32)ShiftedLong >> (slong32)tempchar);

It appears, I am still having the same problem. What it now appears, based on this, is that it is not possible to right shift a signed variable. Is this true or is there a way around this?

Any help you can give me would be appreciated. Thanks!]]> <![CDATA[Circular logic with rule 12.1]]> https://forum.misra.org.uk/showthread.php?tid=993 Mon, 28 Oct 2013 22:30:49 +0000 jbrookley]]> https://forum.misra.org.uk/showthread.php?tid=993
I had a violation for rule 10-5 (the result of a]]>
I had a violation for rule 10-5 (the result of a]]> <![CDATA[Rule 12.4 - Do not use expressions with side effects]]> https://forum.misra.org.uk/showthread.php?tid=990 Thu, 24 Oct 2013 22:17:31 +0000 jbrookley]]> https://forum.misra.org.uk/showthread.php?tid=990
I am having a problem with rule 12.4 (Do not use expressions with side effects in the right hand operand of a logical '&&' operator). My code is as follows:

[code]if ((DualDAC == 0) && (ADC1Flag ]]>
I am having a problem with rule 12.4 (Do not use expressions with side effects in the right hand operand of a logical '&&' operator). My code is as follows:

[code]if ((DualDAC == 0) && (ADC1Flag ]]> <![CDATA[MISRA2004-12_7-3 - Underlying type of LHS operand]]> https://forum.misra.org.uk/showthread.php?tid=989 Thu, 17 Oct 2013 23:29:22 +0000 jbrookley]]> https://forum.misra.org.uk/showthread.php?tid=989
[code]typedef signed short sshort16;

struct DACStruct
{
sshort16 Off;
};

struct DACStruct DACData;

DACData.Off = (sshort16)(EEPROM_BANK1[1]) + (((sshort16)(EEPROM_BANK1[0])) ]]>
[code]typedef signed short sshort16;

struct DACStruct
{
sshort16 Off;
};

struct DACStruct DACData;

DACData.Off = (sshort16)(EEPROM_BANK1[1]) + (((sshort16)(EEPROM_BANK1[0])) ]]> <![CDATA[MISRA C - Rule 12.12]]> https://forum.misra.org.uk/showthread.php?tid=983 Wed, 18 Sep 2013 07:00:06 +0000 Akhil]]> https://forum.misra.org.uk/showthread.php?tid=983
1. int i;
2. float f=2.1;
3. i=(int)f >>2; //Typecasting should actually take care of the bit implementation of floats

Also, If its a violation to Rule 12.12..Does that mean all typecasts (from float to any other type) should also be considered as violationg this rule..?]]>
1. int i;
2. float f=2.1;
3. i=(int)f >>2; //Typecasting should actually take care of the bit implementation of floats

Also, If its a violation to Rule 12.12..Does that mean all typecasts (from float to any other type) should also be considered as violationg this rule..?]]> <![CDATA[Rule 12.6 and functions taking/returning Boolean values.]]> https://forum.misra.org.uk/showthread.php?tid=880 Fri, 10 Feb 2012 09:22:32 +0000 zaffanella]]> https://forum.misra.org.uk/showthread.php?tid=880 "Expressions that are effectively Boolean should not be used as operands to operators other than ..."
The list of the allowed operators has been corrected in TC1 to include &&, ||, !, =, ==, != and ?:

What about the function call operator () ?

If a Boolean value (by enforcement or by construction) is used as an argument to a function having a parameter whose type is Boolean (by enforcement), are we violating Rule 12.6? For instance:
Code:
typedef /* Boolean-by-enforcement type */ bool_t;
void foo(bool_t b);

void bar(int32_t a, int32_t b) {
  bool_t b = (a == b);
  foo(b); /* Non-compliant? */
}

A similar conversion problem exists when returning a Boolean value. In this case Rule 12.6 never applies (even though a Boolean value is being "abused") merely because, strictly speaking, the return statement is not an operator. For instance:
Code:
int32_t bar(int32_t a, int32_t b) {
  bool_t b = (a == b);
  return b; /* Compliant? */
}

Are the two examples above matching what was really meant by Rule 12.6 and TC1?]]> "Expressions that are effectively Boolean should not be used as operands to operators other than ..."
The list of the allowed operators has been corrected in TC1 to include &&, ||, !, =, ==, != and ?:

What about the function call operator () ?

If a Boolean value (by enforcement or by construction) is used as an argument to a function having a parameter whose type is Boolean (by enforcement), are we violating Rule 12.6? For instance:
Code:
typedef /* Boolean-by-enforcement type */ bool_t;
void foo(bool_t b);

void bar(int32_t a, int32_t b) {
  bool_t b = (a == b);
  foo(b); /* Non-compliant? */
}

A similar conversion problem exists when returning a Boolean value. In this case Rule 12.6 never applies (even though a Boolean value is being "abused") merely because, strictly speaking, the return statement is not an operator. For instance:
Code:
int32_t bar(int32_t a, int32_t b) {
  bool_t b = (a == b);
  return b; /* Compliant? */
}

Are the two examples above matching what was really meant by Rule 12.6 and TC1?]]> <![CDATA[Rule 12.6]]> https://forum.misra.org.uk/showthread.php?tid=785 Wed, 27 Oct 2010 15:55:39 +0000 azukich]]> https://forum.misra.org.uk/showthread.php?tid=785
If(TRUE==TRUE) ...

So if TRUE is a Boolean. “==” is not of &&, ||, !. We report this as a violation, since the code should look like
If(TRUE) ...

Many people have debated this. Are we misunderstanding this?]]>
If(TRUE==TRUE) ...

So if TRUE is a Boolean. “==” is not of &&, ||, !. We report this as a violation, since the code should look like
If(TRUE) ...

Many people have debated this. Are we misunderstanding this?]]> <![CDATA[12.4, reading volatile side effect]]> https://forum.misra.org.uk/showthread.php?tid=783 Wed, 13 Oct 2010 07:29:46 +0000 jdp]]> https://forum.misra.org.uk/showthread.php?tid=783
It's the first Misra compliant project I'm involved in and I've some troubles to understand some rules. On in particular is rule 12.4. I've some expression like

Code:
if (xxx && REGISTER)
where REGISTER is a deference to a volatile pointer (represents the content of a microcontroller register) declared as following:

Code:
#define REGISTER            (*((uword volatile *) 0xEA2CU))

The right and of && doesn't comply to rule 12.4 because of the volatile access. I don't understand why reading a volatile content is not Misra compliant. The problem is that registers access are defined as volatile and I don't know how to overcome this to make my statement compliant.

Thanks for your help.]]>
It's the first Misra compliant project I'm involved in and I've some troubles to understand some rules. On in particular is rule 12.4. I've some expression like

Code:
if (xxx && REGISTER)
where REGISTER is a deference to a volatile pointer (represents the content of a microcontroller register) declared as following:

Code:
#define REGISTER            (*((uword volatile *) 0xEA2CU))

The right and of && doesn't comply to rule 12.4 because of the volatile access. I don't understand why reading a volatile content is not Misra compliant. The problem is that registers access are defined as volatile and I don't know how to overcome this to make my statement compliant.

Thanks for your help.]]> <![CDATA[Rule 12.5: OR sequence without parentheses not compliant?]]> https://forum.misra.org.uk/showthread.php?tid=774 Fri, 17 Sep 2010 07:51:28 +0000 pkrebs]]> https://forum.misra.org.uk/showthread.php?tid=774
I have a question regarding Rule 12.5: "The operands of a logical && or || shall be primary-expressions."

I often use constructs of the form "(condition1) || (condition2) || ... || (condition n)" to test for illegal values of a set of input parameters in functions (see example below), which should be compliant as far as I understand the rule text without the need of extra parentheses to group the conditions (parenthesised expression, sequence of only logical ||). However, my analysis tool (flexelint, v9.00e) complains about this construct ("non-primary expression"). Did I got something wrong about the definition of "primary expression" or is this a false positive?

Thanks in advance for any answers.

Example:

Code:
if ((start >= end) || (start > 7U) || (end > 8U))      /* raises rule violation */
{
    /* do something */
}
else
{
    /* do something different*/
}


if ((start >= end) || ((start > 7U) || (end > 8U)))      /* does not raise violation, note extra parentheses around second and third condition */
{
    /* do something */
}
else
{
    /* do something different*/
}
]]>
I have a question regarding Rule 12.5: "The operands of a logical && or || shall be primary-expressions."

I often use constructs of the form "(condition1) || (condition2) || ... || (condition n)" to test for illegal values of a set of input parameters in functions (see example below), which should be compliant as far as I understand the rule text without the need of extra parentheses to group the conditions (parenthesised expression, sequence of only logical ||). However, my analysis tool (flexelint, v9.00e) complains about this construct ("non-primary expression"). Did I got something wrong about the definition of "primary expression" or is this a false positive?

Thanks in advance for any answers.

Example:

Code:
if ((start >= end) || (start > 7U) || (end > 8U))      /* raises rule violation */
{
    /* do something */
}
else
{
    /* do something different*/
}


if ((start >= end) || ((start > 7U) || (end > 8U)))      /* does not raise violation, note extra parentheses around second and third condition */
{
    /* do something */
}
else
{
    /* do something different*/
}
]]> <![CDATA[12.7 and narrowing signed integers]]> https://forum.misra.org.uk/showthread.php?tid=770 Tue, 31 Aug 2010 21:19:22 +0000 tjotjos]]> https://forum.misra.org.uk/showthread.php?tid=770
I need to transmit a 7-bit signed integer (values are restricted -64 - +63). My current method, shown below, seems to be inconsistent with 12.7.
Code:
int_8 s8a;
uint_8 u8b;
...
u8b = s8a & 0x7F;

Is the following an acceptable solution, or a violation of 10.1? Do I need to use a deviation here for the 7-bit integer?
Code:
int_8 s8a;
uint_8 u8b;
...
u8b = ((uint_8)s8a & 0x7F;

Thank you for your help!]]>
I need to transmit a 7-bit signed integer (values are restricted -64 - +63). My current method, shown below, seems to be inconsistent with 12.7.
Code:
int_8 s8a;
uint_8 u8b;
...
u8b = s8a & 0x7F;

Is the following an acceptable solution, or a violation of 10.1? Do I need to use a deviation here for the 7-bit integer?
Code:
int_8 s8a;
uint_8 u8b;
...
u8b = ((uint_8)s8a & 0x7F;

Thank you for your help!]]> <![CDATA[Generalized Question about #12.6 and Preprocessor Directives]]> https://forum.misra.org.uk/showthread.php?tid=765 Tue, 17 Aug 2010 17:39:51 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=765 <![CDATA[12.6 for Preprocessor Directives?]]> https://forum.misra.org.uk/showthread.php?tid=764 Thu, 05 Aug 2010 13:46:46 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=764
Code:
#if ! defined A
#endif
?

Could a case not be made the result of 'defined' is an "effectively Boolean Expression"?]]>
Code:
#if ! defined A
#endif
?

Could a case not be made the result of 'defined' is an "effectively Boolean Expression"?]]> <![CDATA[Was something missed for 12.6 about "?:"?]]> https://forum.misra.org.uk/showthread.php?tid=735 Thu, 06 May 2010 15:25:32 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=735 <![CDATA[Rules 12.1 and 12.5 and unary operators]]> https://forum.misra.org.uk/showthread.php?tid=729 Thu, 22 Apr 2010 08:06:38 +0000 pmhill]]> https://forum.misra.org.uk/showthread.php?tid=729
However, in rule 12.1, it is stated that no parentheses are required for the operand of a unary operator
while in rule 12.5 it is said that the operands of the logical operators && and || must be primary expressions;
the latter is exemplified in 12.5 with the following example:

if ( x && ( !y ) ) /* make !y primary */

So for rule 12.1, is something like:
if ( x && !y )
...
a violation?]]>
However, in rule 12.1, it is stated that no parentheses are required for the operand of a unary operator
while in rule 12.5 it is said that the operands of the logical operators && and || must be primary expressions;
the latter is exemplified in 12.5 with the following example:

if ( x && ( !y ) ) /* make !y primary */

So for rule 12.1, is something like:
if ( x && !y )
...
a violation?]]>