[Groff] on type bool

[Bernd Warken]

In ancient C and C++, Boolean values such as results of equality tests
were of standard type `int'.  ANSI C++, however, implemented a
stand-alone type `bool' for Boolean values.  This type is an integral
part of the C++ language, some operators rely on having this type.
Unfortunately, most old C++ compilers do not provide such a type.

The solution to this problem is to have the existence of `bool' tested
with `configure' and write some kind of replacement for systems that
do not have this type.

Though being an integer type, `bool' is not interchangeable with any
of the other integer types in C/C++.  The (annotated) ANSI C++
par. 3.6.1 standard specifies `bool' as a funcamental type with the
following qualities:

   1) `bool' is a unique signed integral type.
   2) A `bool' value may be converted to `int' by promotion:
      `true' converts to 1, `false' converts to 0.
   3) A numeric or pointer value may be implicitly converted to `bool'.
      A zero value becomes `false'; a non-zero value become `true'.
   4) The relational operators yield `bool' values.

Because of (3), `bool' is not compatible with `int' and cannot be
fully faked.  The closes approximation is to write a class; but it
would need more than 100 methods and some very unlikely border cases
would fail nevertheless.

A good compromise for compatibly have a `bool' type is the following
strategy:

a) Write a test function for `bool' in `aclocal.m4' that sets a
variable `HAS_BOOL' when `bool' is available. (already done)

b) Enable this test in `configure.in'. (already done)

c) Implement `bool' as follows:

#ifdef HAS_BOOL
#  define to_bool(x) bool((x))
#else // not HAS_BOOL
#  define bool int
#  define false 0
#  define true 1
#  define to_bool(x) (x == 0) ? 0 : 1 
#endif // not HAS_BOOL

Together with the requirement that all casting to `bool' must be
performed via `to_bool()', this fulfills the ANSI C++ `bool' rules
(1)-(4) above.

d) In order to be able to transparently use `bool', the above
implementation must be kept in a header file that is included anyway
in any .cc source file.  `groff-source/src/include/lib.h' seems to be
a good choice.  Or should it go to a file of its own.

Comments welcome.

Bernd Warken