svn commit: r283088 - head/sys/ddb

[Bruce Evans]

On Mon, 18 May 2015, Pedro Giffuni wrote:

>> Il giorno 18/mag/2015, alle ore 20:48, Bruce Evans <brde at optusnet.com.au> ha scritto:
>>
>> On Mon, 18 May 2015, Pedro F. Giffuni wrote:
>>
>>> Log:
>>> ddb: stop boolean screaming.
>>>
>>> TRUE --> true
>>> FALSE--> false
>>>
>>> Hinted by:	NetBSD
>>
>> This is not just churn to a style regression, but a type mismatch.
>
> It is an attempt to reduce differences with NetBSD.

For that, apply the reverse change to NetBSD.

> One of the complaints of hear from newcomers to the ddb code is that
> the format is old-fashioned (it still had pre-ANSI headers not long ago)
> and unmaintained.

It is fairly well maintained (not churned to unimprove its portability).
Why would newcomers want too look at it?

>>> Modified: head/sys/ddb/db_break.c
>>> ==============================================================================
>>> --- head/sys/ddb/db_break.c	Mon May 18 22:14:06 2015	(r283087)
>>> +++ head/sys/ddb/db_break.c	Mon May 18 22:27:46 2015	(r283088)
>>> @@ -155,12 +155,12 @@ db_find_breakpoint_here(db_addr_t addr)
>>> 	return db_find_breakpoint(db_map_addr(addr), addr);
>>> }
>>>
>>> -static boolean_t	db_breakpoints_inserted = TRUE;
>>> +static boolean_t	db_breakpoints_inserted = true;
>>
>> This code hasn't been churned to use the boolean type.  It still uses
>> boolean_t, which is plain int.  TRUE and FALSE go with this type.  true
>> and false go with the boolean type.  This probably makes no difference,
>> because TRUE happens to be implemented with the same value as true and
>> there are lots of implicit versions between the types.
>
> Yes, I noticed the return types are still ints. It doesn’t look difficult
> to convert it to use a real boolean type.  In any case, I would prefer to go
> forward (using bool) instead of reverting this change.

That wuld be sideways.

I forgot to mention (again) in my previous reply that boolean_t is a mistake
by me.  KNF code doesn't even use the ! operator, but uses explicit
comparison with 0.  The boolean_t type and TRUE and FALSE are from Mach.
They were used mainly in ddb and vm, and are still almost never used in
kern.  I used to like typedefs and a typedef for boolean types, and didn't
know KNF very well, so in 1995 I moved the declaration of boolean_t from
Mach vm code to sys/types.h to try to popularize it.  This was a mistake.
Fortunately, it is still rarely used in core kernel code.

The boolean type is also almost never used for syscalls.  In POSIX.1-2001,
<stdbool.h> is inherited from C99, but is never used for any other POSIX
API.  Using it for syscalls would mainly cause portability problems.

>> The boolean type is almost useless since C's type system is too weak to
>> distinguish between plain int used as a boolean and pure boolean.  If
>> it were stronger, then it would complain about all the implicit conversions
>> between int and boolean, and the boolean type would be harder to use for
>> other reasons.
>
> And I would like that to happen, but it would probably break a lot of legacy code.
> I thought boolean_t was a transition type.

It is the Mach spelling of a type suitable for holding boolean values.  There
aren't many possible spellings, but even the limited spellings cause namespace
problems.  C99 uses the spelling _Bool for the basic type to keep away from
the application namespace.  Applications only get the spellings bool, true
and false if they include <stdbool.h>.  These spellings are very likely to
conflict with application spellings for a nonstandard implementations of the
boolean type.  The kernel is not careful about this :-(.  Someone added
the pollution bool, true and false to sys/types.h.  Otherwise, your change
wouldn't have compiled.  The pollution for boolean_t is not as bad.
boolean_t is in the POSIX namespace for sys/types.h, and TRUE and FALSE are
only defined in sys/param.h.

It is interesting that true and false are macros of type int suitable for
use in cpp expressions, with values precisely 0 and 1.  They are just
like TRUE and FALSE, except they are specified in a standard while TRUE
and FALSE are not even documented in a man page AFAIK (in section 9 man
pages, some functions are documented as returning TRUE or FALSE, but what
these are is not documented).  This makes the boolean type system even
weaker than I thought, and your change not even a type error -- since
true and false don't have type bool, the compiler cannot do any extra
type checking for them.

Bruce