Re: stdbool.h test v. Compaq C on Tru64

[Paul Eggert]

address@hidden (Steven M. Schweda) writes:

>    Now, having failed that (deluxe, rigorous) test, we can advance to
> the (newly revised) gnulib stdbool.h, which does _so_ much better:

gnulib stdbool.h is not intended as a complete replacement for
stdbool.h; it is intended only to be a replacement sufficient for
programs that stick to a limited subset of stdbool, a subset that is
described in the replacement stdbool.h file.

autoconf's test for bool is intended to make sure that your bool
conforms to C99.  This cannot be done portably in C89 code, so
gnulib's stdbool.h cannot implement it.

The engineering question here is: is it better for a portable program
to rely on a system's stdbool.h, even when it's known that the system
stdbool.h has some bugs (but we don't know much more about it than
that); or should the program rely on a portable C89 implementation of
stdbool.h whose specification and behavior is a well-understood subset
of C99?

In practice, the gnulib approach is to prefer the latter.  This
approach works fairly well in practice.  Its main problem has been
with that enum put into the replacement stdbool.h, which was put there
only for debugging purposes.  I've long been suspicious of that enum
and have long argued that it be taken out, so to some extent I'm
"happy" that you provided more evidence against it.  With it gone, I
doubt whether we'll see similar problems in the future.

>    I remain curious as to why the variable scope change which I
> suggested for the autoconf stdbool.h test would in any way violate its
> (claimed) purpose,

Autoconf and gnulib have somewhat-differing goals here.  Autoconf is
trying to be super-safe about whether stdbool.h works; gnulib is
trying to supply an adequate replacement.