3

I am reviewing coding guidelines for C and we still have the guideline to typedef uint8_t for booleans. I work for a company in the automotive industry, therefore doing embedded software and usually working with Renesas micro-processors alongside GreenHills compilers.

I think that since C99 has been out there for so many years, the type definition is redundant and I would expect all compilers for modern platforms to support _Bool. So, is it still worth having the typedef?

Bonus question: I am trying to put together some guidelines for C++. I have a relatively limited background using C++, but again my opinion is that a typedef for bool should not be at all beneficial. Should we use the fundamental C++ bool type or is there any reason why we should use a custom typedefed T_BOOL instead?

GiatManos
  • 53
  • 6
  • 2
    If you're writing C++, use `bool`, no question. If you're writing relatively modern C, include `stdbool.h` and use `bool` from there. _However_ that's arguably a matter of opinion, and very possibly not an opinion shared by MISRA or whatever safety-critical coding standard you're inevitably using for automotive work. – Edd Inglis Nov 07 '19 at 11:09
  • Microsoft uses `BOOL` as a typedef for `int` so in C I've always just done it that way. Any type works if you're returning 0 or 1. – Irelia Nov 07 '19 at 11:44
  • @EddInglis we follow MISRA 2012 of course but the MISRA standard is not very clear regarding the use of ```bool``` and thus my question. I am more interested to get some insight from other professionals on the matter. I understand that this is not a clear black and white answer. – GiatManos Nov 07 '19 at 11:51
  • 1
    @usr, I'm sorry I can't provide specifics, I was just giving a note of caution, since I know MISRA can be funny about things that everyone else thinks were decided long ago. – Edd Inglis Nov 07 '19 at 11:54
  • 1
    If you think a custom Boolean type might not be needed because it is in C99, then you need to determine whether these guidelines you are possibly revising need to support pre-C99 implementations. That is the question: What are the requirements or goals of the guidelines? Find out, as a matter of fact whether the guidelines will be used with pre-C99 implementations, not, as a matter of opinion, whether there is “worth” to specifying a custom Boolean type. – Eric Postpischil Nov 07 '19 at 12:01
  • MISRA-C:2012 says that you should use _a_ boolean type but doesn't specify which one. This is because it maintains backwards compatibility with C90. It has lots of rules for how to treat boolean types however, and prevents using them together with various forms of arithmetic. – Lundin Nov 08 '19 at 07:34

3 Answers3

1

It is simple:

  • If you are using standard C, then use bool from stdbool.h. _Bool is also fine. Ugly typedefs are not ok and bad practice.
  • If you are forced to work with old C90, you have to use an ugly typedef of some sort.

Assuming C90:

There is absolutely no harm in using an 8 bit type for the boolean typedef. An 8 bit type will save a little bit of RAM. It can be done like this:

typedef uint8_t BOOL;
#define FALSE 0u
#define TRUE  1u

The most common form is however probably a typedef enum { FALSE, TRUE } BOOL;.

Never use all lower case! Since bool, false and true will collide with the standard if you port to a standard C compiler.

All of these home-brewed forms are bad practice and an obsolete way of writing C. There are no excuses left for sticking with dangerous C90, particularly not in automotive systems that tend to be safety-critical.

As for MISRA-C:2012, it simply states that you should have some sort of boolean type. It maintains backwards compatibility with C90 and therefore doesn't enforce bool. It has lots of rules for how to treat boolean types however, and prevents using them together with various forms of arithmetic.

For compatibility with C++ you should definitely use standard C bool. That type was explicitly designed with C++ compatibility in mind.

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

For new code, there is really no reason to redefine the standard types - In our company, we require , implying use of bool, true, and false, as it prevents different teams and developers from developing their own (sometimes slightly incompatible) variants of those types.

For older code, which has to deal with previously declared bool/true/false, potentially from legacy frameworks, it is sometimes useful to alias (via typedef, or #define) existing types into _Bool. This is usually an issue for frameworks and not specific programs. Examples include X11 (Boolean) , Xt (_XtBoolean), ...

I believe the reason for including both _Bool and bool was to allow existing code that has already created 'bool' to continue workinng without having to make code changes as a result of introducing 'standard' bool, false and true.

dash-o
  • 13,723
  • 1
  • 10
  • 37
-2

In the instant you are (ab)using the C promotion rules to store a boolean in anything other than the type of the expression delivered by the comparison operators, that is int, you are in a state of sin. On a more serious note: I can't envision a case where the type in which I store a boolean piece of information would matter, except for vast amounts of booleans, and having written quite a few mission critical pieces of Automotive Software, I can hardly imagine a case where such a data structure could be useful. Nearly every information that I ever handled which carried a yes/no decision also carried a bunch of related data and the natural storage scheme therefore was a struct. I never shied away from bitfields, no matter what the current MISRA standard would say about it (the case against them crumbles to dust if you think through the counterarguments with your "Sane Safety Software Expert" hat on). When this was not the case, it was some global flag and therefore the size of the storage format was no concern. So the question is, which are the remaining applications where the storage format of a boolean would matter? The only one that I can think of is stack size or rather, losing the possibility to do a call with parameters only in registers if you didn't choose the smallest available size. This immediately raises two counterarguments: functions with many loosely coupled boolean parameters are extremely suspicious and even if they exist, neither performance nor memory consumption should in any way depend on them (if they are bottlenecks, thats extremely suspicious too). There may be a small win in maximum stack size if you have a call hierarchy with a boolean here and there, but this is IME not the place for micro optimization.

To give a TL;DR answer: the format should not deviate from what the (new) programmers on your team are expecting and that is most likely the one which was in broad use/standard during the last decade. If the stored type of your booleans really matter that much I, completely unasked, dare to remote-diagnose an software construction problem.

Vroomfondel
  • 2,704
  • 1
  • 15
  • 29