[En-Nut-Discussion] Nut/OS finally moving to C99 types

[Thiago A. Corrêa]

Hi,

>  > It makes a lot more sense when the return value is only for indicating
>  > success or failure, or enable/disable, etc.... If only two values are
>  > valid, there is no reason to use a broader type.
>
>  I have 3 questions:
>
>  Will the compiler accept "bool v = 2;", "int x = false" or "if (v == -1)"?

Yes. Although all conversions from integers to _Bool will be be as
(6.3.1.2 Boolean type)

When any scalar value is converted to _Bool, the result is 0 if the
value compares equal
to 0; otherwise, the result is 1.

and, the compiler will prefer to convert integer types to _Bool than
the other way around (6.3.1.1 Boolean, characters, and integers):

— The rank of _Bool shall be less than the rank of all other standard
integer types.

Thus, the if should should be true. Albeit, conversions from numeric
types to _Bool should issue a warning similar to assignments from ints
to chars, about the loss of information in the conversion. So,
unintended errors like that could be caught, which is by itself quite
compeling reason to use bools.

>  What is the size of a bool and the size of an element in an array of
>  booleans?

I couldn't find that on the TCs (which are free, the ISO/IEC 9899:1999
document actually costs 360 dollars). But I don't think it's much
different than using bitfields. I suppose sizeof a struct with 8 bools
should be the same as the sizeof a char bitfield. sizeof(bool) should
yield 1, and sizeof arrays should always return the number of elements
AFAIK.

>  Is stdbool.h available in any of the compiler runtimes we are using
>  right now (gccavr, arm-elf-gcc, iccavr)?
>

It should in order to comply with C99. Winavr has it, didn't check the
arm toolchain, but should as well since it's based on gcc. iccavr, is
quite full of bugs, so it's doubtfull. I have moved away of iccavr for
quite sometime, so I can't check that. Anyway, stdbool.h just defines
4 macros:

- bool expands to _Bool.
- true expands to 1
- false expands to 0
- __bool_true_false_are_defined expands to 1

So, we could provide one that bool expands to unsigned char if the
compiler is non-compliant, the same as stdint.h


>
>  > It provides the compiler with optimization opportunities,
>
>  I'm not sure about this, but your answers to the questions above may
>  convince me - in either way.

This is most likely implementation defined. I don't know where to look
for an ABI document, and I suppose there isn't one for embedded
platforms anyway.

>
>  > and I'm sure
>  > the standards committee have seen other advantages other than just
>  > syntax sugar, although that is reason enough in terms of readability.
>
>  In that specific sense, can you specify "readability"? In my view,
>  readability implies consistency. If some functions return 0 and -1 while
>  others use true and false for the same purpose, readability suffers.

Ok, you had me on the return types, but let's not be hasty in banning
bools, we could use them in structs and arguments when they make
sense.

>  Let's assume a new function
>
>  bool foocmp(itm1, itm2);
>
>  How to explain a newbie the following difference
>
>  if (strcmp(str1, str2))...
>  but
>  if (foocmp(str1, str2) == false)...
>
>  (or too completely confuse him "if (strcmp(str1, str2) != false)" :-))
>

strcmp returns the difference of the two strings in a way that it can
be used for sorting. That's probably a bad example, but I see what you
mean. Regardless, it's quite possible to keep consistency. Think of
isalpha() for instance.

Anyway new functions could take bools as parameters *hint*

>
>  > States without any doubt that the variable can only assume 2 states,
>  > no more, no less. No grep'ing for that variable to see the possible
>  > states.
>
>  If you are more familiar with other languages like C++ or PHP, this is
>  indeed confusing. If C is your daily dope, then there's usually no
>  doubt, that a result value of 0 means "Everything is fine" and that it
>  never means "false".
>

Not quite, see isdigit(), isalpha() :)
There isn't much consistency in C either.
A good API should be clear, regardless of unstated rules hehe.


Kind Regards,
   Thiago A.Correa