Does MISRA C 2012 say not to use bool

Question

I am in the early stages of framing stuff out on a new project.

I defined a function with a return type of "bool"

I got this output from PC-Lint

    Including file sockets.h (hdr)
bool sock_close(uint8_t socket_id);
^
"LINT: sockets.h (52, 1) Note 970: Use of modifier or type '_Bool' outside of a typedef [MISRA 2012 Directive 4.6, advisory]"

I went ahead and defined this in another header to shut lint up:

typedef bool bool_t;

Then I started wondering why I had to do that and why it changed anything. I turned to MISRA 2012 Dir 4.6. It is concerned mostly about the width of primitive types like short, int, and long, their width, and how they are signed.

The standard does not give any amplification, rational, exception, or example for bool.

bool is explicitly defined as _Bool in stdbool.h in C99. So does this criteria really apply bool?

I thought _Bool was explicitly always the "smallest standard unsigned integer type large enough to store the values 0 and 1" according to section 6.2.5 of C99. So we know bool is unsigned. Is it then just a matter of the fact that _Bool is not fixed width and subject being promoted somehow that's the issue? Because the rational would seem to contradict that notion.

Adherence to this guideline does not guarantee portability because the size of the int type may determine whether or not an expression is subject to integer promotion.

How does just putting typedef bool bool_t; change anything - because I do nothing to indicate the width or the signdedness in doing so? The width of bool_t will just be platform dependent too. Is there a better way to redefine bool?

A type must not be defined with a specific length unless the implemented type is actually of that length

so typedef bool bool8_t; should be totally illegal.

Is Gimpel wrong in their interpretation of Directive 4.6 or are they spot on?

Answer 1

Use of modifier or type '_Bool' outside of a typedef [MISRA 2012 Directive 4.6, advisory]

That's nonsense, directive 4.6 is only concerned about using the types in stdint.h rather than int, short etc. The directive is about the basic numerical types. bool has nothing to do with that directive whatsoever, as it is not a numerical type.

For reasons unknown, MISRA-C:2012 examples use a weird type called bool_t, which isn't standard. But MISRA does by no means enforce this type to be used anywhere, particularly they do not enforce it in directive 4.6, which doesn't even mention booleans. MISRA does not discourage the use of bool or _Bool anywhere.

Is Gimpel wrong in their interpretation of Directive 4.6

Yes, their tool is giving incorrect diagnostics.

In addition, you may have to configure the tool (if possible) to tell it which bool type that is used. 5.3.2 mentions that you might have to do so if not using _Bool, implying that all static analysers must understand _Bool. But even if the bool type is correctly configured, dir 4.6 has nothing to do with it.

Answer 2

A potential concern with Boolean types is that a lot of code prior to C99 used a single-byte type to hold true/false values, and a fair amount of it may have used the name "bool". Attempting to store any multiple of 256 into most such types would be regarded as storing zero, while storing a non-zero multiple of 256 into a c99 "bool" would yield 1. If a piece of code which uses a C99 "bool" is ported into a piece of code that uses a typedef'ed byte, the resulting code could very easily malfunction (it's somewhat less likely that code written for a typedef'ed byte would rely upon any particular behavior when storing a value other than 0 or 1).