Re: Booleans

[Paul Eggert <eggert@cs.ucla.edu>]

Eli Zaretskii wrote:

> I'm not sure I understand why we want such a wholesale
> replacement of 0/1 with false/true.

It's no big deal and we could easily change it back if
desired.  I did it primarily because Stefan suggested that I
do so, while changing int to bool etc.

> why is it a good idea to convert everything, including bitfields (which
> required introduction of a new non-standard typedef), into booleans?

If a value is a boolean, it typically makes things easer on
the reader, the debugger, etc. to know that it's a boolean
and not an integer, so that one needn't worry about values
other than 0 and 1.

bool_bf is a response to trunk bzr 115272, which used 'bool
inhibit_shrinking : 1;'.  This is not portable to pre-C99
platforms.  I temporarily fixed that by changing 'bool' by
'unsigned' in trunk bzr 115280, but for maintainability
'bool' is indeed better, and 'bool_bf' attempts to support
this while still maintaining portability to pre-C99
platforms.

If we could assume C99 or later, we could get rid of bool_bf
and just use bool.  I'm thinking of proposing such an
assumption for after the next release.  This would allow us
to use some other C99 features, such as declarations after
statements, which would make Emacs easier to maintain.

> should have been a separate commit, as
> it is not a mechanical replacement, far from it.

It was a judgment call.  Perhaps I should have separated it
out, though it's no big deal.  It was a case of an int value
being used as a boolean with values 0 and -1.

>   -#if 0
>   +#if false
> 
> ... I'm afraid I don't see the point

I tried to be reasonably systematic in replacing uses of 0
and 1 as booleans in the set of files that I was looking at;
this included the use of booleans in preprocessor
expressions.  It would be an odd style to use '0' for false
preprocessor expressions, while using 'false' for false
expressions everywhere else.