Re: [Bug-gnulib] stdbool_.h bug breaks coreutils CVS sort on Alpha GCC 2.95.4

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> > In C99, sizeof(_Bool) must be 1
> 
> Can you please point to the paragraph in ISO C 99 that says this?

Sorry, I was mistaken.  I confused "rank" with "size".  Apparently C99
allows _Bool to be any nonzero size, so long as it promotes to int.

However, there is still a point to using signed char, even though I
used the wrong reasoning.  C99 requires that _Bool must have a rank
smaller than signed char (section 6.3.1.1 parapgraph 1), and that the
range of values of bool must therefore be a subrange of the range of
values of signed char (section 6.2.5 paragraph 8).  The only way to
implement this requirement portably in C89 is to have bool be
equivalent to signed char.

Here is another, weaker argument against using an enum.  The following
program is strictly conforming C99:

   #include <stdbool.h>
   #undef false
   int const false = 0;

and the enum doesn't allow this.  I wouldn't do that in any program
that I wrote, as it's explicitly stated to be obsolescent in the
standard; but it is a conformance issue, albeit a theoretical one.

More practically, do you know of any important C99 platforms where
sizeof (_Bool) isn't 1?  If so, I'll have to remember not to use bool
arrays if space is a concern.  If not, then we should make _Bool be
signed char, even if the standard doesn't strictly require this,
simply to minimize porting hassles.


However, if you still really want the enum despite the above
discussion, here is a simpler way to get it to work as desired:

  enum { bool_is_signed = -1, false, true };

With this definition, C89 guarantees that 'false' and 'true' promote
to int, not unsigned int.  I'd prefer this solution to using Autoconf
to test whether enums are signed, since it's simpler and will have
less variance on different platforms.  But I still don't see any
advantage of an enum over signed char.


> Also C99 specifies that "The rank of _Bool shall be less than the rank
> of all other standard integer types", which can not be fulfilled with
> any <stdbool.h> emulation. Similarly for the requirement that
> (_Bool) -0.25f == 1.

Absolutely.  We cannot implement <stdbool.h> precisely.  The best we
can do is support a portable subset of its behavior, the subset that
is most likely to be used by real programs.  The changes I proposed
for <stdbool_.h> were motivated by actual bug reports in the field,
not by theoretical concerns; otherwise I wouldn't have bothered.

It might be helpful to describe the precise subset of C99 <stdbool.h>
that is implemented correctly.  How about this for a first cut?  It
could be put into a comment in <stdbool_.h>.

/* Usage suggestions:

   Programs that use this substitute for C99's <stdbool.h> should
   limit themselves to a portable subset of C99.

   For portability to C89:

        - Unlike C99, there is no automatic conversion of nonzero
          values to 1 when converting to bool.  Therefore, portable
          programs should convert only zero and 1 to the bool data
          type.  (Programs can also convert floating-point numbers
          greater than 1 and less than 2 to bool, but that's not
          likely to be useful.)

        - Programs should include <stdbool.h> before using _Bool.

        - Programs should not assume that _Bool is a typedef; it might
          be a macro.

   For portability to future C standards:

        - Programs should not undefine the macros bool, true, and false,
          as C99 lists that as an obsolescent feature.

   Also, it is suggested that programs use bool rather than _Bool;
   this isn't required, but bool is more common and it's better to use
   a consistent style.  */