I'm getting the next MISRA error: Rule-10.4 The operands of this equality operator are expressions of different 'essential type' categories (Boolean and unsigned). The code is showed below:
#define TRUE (1!=0)
#define FALSE (0!=0)
typedef unsigned char boolean;
boolean active;
getActive(&active);
if (TRUE == active) <<<<<<<<<<<< HEre is the conflicting line
{
// DO Something
}
If I remove the TRUE :
if (active)
MISTA Rule 14.4 appears: "Controlling expression is not an 'essentially Boolean' expression"
So I cannot figure out the solution,
I see that using
#define TRUE 1U
#define FALSE 0U
solves the problem but I'm afraid I cannot afford this solution since I'm using a big inherited code from a 3rd party using the (1!=0) expression. I guess that expression is more 'smart' and portable since in some systems the meaning of TRUE/ FALSE might chenge to 0/1 but I wonder if I can keep the:
#define TRUE (1!=0)
#define FALSE (0!=0)
and write my conditional expressions in a manner to cope with the MISRA issues
Thanks to all for the answers and comments.
Unfortunately I'm not allowed to use stdbool.h, I'm using an AUTOSAR (automotive) stack, and they don't use any of the standard libraries.
I'd prefer don't to trick the MISRA tool to indicate the boolean type, I think it would be something that we'd have to export to any PC of the team (ad-hoc solution).
Thanks to @R about the (1 != 0) clarification; it makes no sense, C is C (not bash or whatever where the true might be 0), and true will always be 1, so unless you are ignorant about the bool value in your programming language the definition as an expression is useless.
I think that for my purposes, the best solution would be to redefine the macros as:
#define TRUE (1U)
#define FALSE (0U)
I've seen the AUTOSAR stack gives me the option to redefine this values in an Integration file.
And this way I keep the compatibility with all my Application code and the existing AUTOSAR stack, and also I don't need to change anything in the inherited code.