2

When I try to add these macros:

#define BOOT_VD_TRUE  ((uint8_t)(0x00U))
#define BOOT_VD_FALSE ((uint8_t)(0x01U))

It violates MISRA C-2012 Rule 10.3: Implicit conversion of (uint8_t)1U from essential type "boolean" to different or narrower essential type "unsigned 8-bit int".

I tried removing type cast but still it considers 0 and 1 as booleans and not integers.

Function Definition is as follows:

uint8_t bootInitFlag(uint8_t Val) 
{ 
   uint8_t bootFlag = Val;
   // Doing something
}

bootInitFlag(BOOT_VD_TRUE);
user16217248
  • 3,119
  • 19
  • 19
  • 37
AYUSH KUMAR
  • 35
  • 5
  • No idea about MISRA but `((uint8_t)(whatever))` will be immediately promoted to `int` anyway. – n. m. could be an AI May 12 '23 at 18:29
  • 4
    You will have to show where they are used that triggers the warning. – Fredrik May 12 '23 at 18:34
  • 2
    The implication from the nomenclature `BOOT_VD_TRUE` is that you *are* using them as booleans. Show the usage: a macro itself isn't error-forming (apart from syntax). – Weather Vane May 12 '23 at 18:45
  • What type do you use to represent the boolean parameter? `_Bool`? In that case, try cast the constant to it rather than `uint8_t`. – Lindydancer May 12 '23 at 18:48
  • Please [edit] your question if you add new information. This is not a forum. – the busybee May 12 '23 at 18:54
  • Just a guess ... Did you try: `#define BOOT_VD_TRUE ((uint8_t)0x00U)` or `#define BOOT_VD_TRUE ((uint8_t)0x00)` – Craig Estey May 12 '23 at 18:54
  • It makes no sense that `0x00` and `0x01` would be considered "essential type boolean". They're perfectly normal integers, which just happen to also be the values of booleans. – Barmar May 12 '23 at 19:26
  • 1
    I just tried this with a well-known commercial lint-style tool (using MISRA 2012 rules), and it doesn't make this complaint. You should contact your vendor - it looks like you have a very trivial example you could share with them. – pmacfarlane May 12 '23 at 19:35
  • Removing TRUE and FALSE from the macro definition worked :) Thanks, Everyone! – AYUSH KUMAR May 13 '23 at 18:13

2 Answers2

1

In order for any MISRA checker to work as intended, it needs to know what your boolean types are. Normally they are bool, true, false unless you are stuck with ancient C90. In that case you need to actively tell the tool what your boolean types are or it can't know that.

A tool which assumes that some of your types are essentially boolean based on the naming is just broken. Bug report it.

Lundin
  • 195,001
  • 40
  • 254
  • 396
0

As Lundin states in his answer, this appears to be a tool configuration issue... talk to your vendor.

--

But... noting your code:

#define BOOT_VD_TRUE  ((uint8_t)(0x00U))   /* ADB notes: TRUE  = 0 */
#define BOOT_VD_FALSE ((uint8_t)(0x01U))   /* ADB notes: FALSE = 1 */

I assume your specifying of TRUE = 0 and FALSE = 1 is intentional? But guaranteed to confuse the heck out of most people... so I strongly advocate using the traditional false = 0, true = 1

--

However...

You don't specify which version of C or which compiler you are using, but unless you are still using a fully-conformant C90-only compiler, the recommendation has to be to use <stdbool.h> (and even in the era of C90, most compilers had adopted the proposed <stdbool.h> as a extension):

And even if you insist on using the intermediate names, you can use:

#include <stdbool.h>

#define BOOT_VD_TRUE  false    // ADB notes: reverse logic retained
#define BOOT_VD_FALSE true     // ADB notes: reverse logic retained

void bootInitFlag( bool Val )  // ADB notes: void, as you're not returning anything
{ 
   bool bootFlag = Val;
   // Doing something
}

...

bootInitFlag( BOOT_VD_TRUE );
Andrew
  • 2,046
  • 1
  • 24
  • 37