On Mon, 18 May 2015, Pedro Giffuni wrote:

Il giorno 18/mag/2015, alle ore 20:48, Bruce Evans <b...@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
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to