Re: svn commit: r283088 - head/sys/ddb
On 05/19/15 10:58, Pedro Giffuni wrote: On 05/19/15 08:45, John Baldwin wrote: ... snip I will disagree with Bruce a bit and put my vote in for replacing boolean_t with bool where it is used. I do think that logically (if not strictly) your commit is a type mismatch as TRUE/FALSE is for boolean_t and true/false are for bool. I agree with Bruce that we probably don't want to use bool for system calls. However, I think using bool in the kernel itself is ok and that we should replace boolean_t with bool. I guess it boils down to the dilemma between modernity and common practice. OK, I know the current change can't stay as-is, and even Bruce admits that boolean_t is a mistake, so I think I will give the bool a try. FWIW, I have a patch for this[1] but it became rather interesting because on MIPS, bool and int are not interchangeable so I am finding some places where the prototypes and the implementation don't match. It will still take me some time (the tinderbox is really slow) but the result should be cleaner. Pedro. [1] https://people.freebsd.org/~pfg/patches/ddb-bool.diff ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r283088 - head/sys/ddb
On Tuesday, May 19, 2015 12:28:05 AM Pedro Giffuni wrote: 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_tdb_breakpoints_inserted = TRUE; +static boolean_tdb_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. OK, I do understand the kernel wants to keep the C dialect somewhat limited, and adding stdbool.h doesn’t buy us any type safety here. I’ll revert the change (prob. tomorrow though). I will disagree with Bruce a bit and put my vote in for replacing boolean_t with bool where it is used. I do think that logically (if not strictly) your commit is a type mismatch as TRUE/FALSE is for boolean_t and true/false are for bool. I agree with Bruce that we probably don't want to use bool for system calls. However, I think using bool in the kernel itself is ok and that we should replace boolean_t with bool. -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r283088 - head/sys/ddb
On Mon, 2015-05-18 at 22:49 -0500, 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. 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. Modified: head/sys/ddb/db_break.c == --- head/sys/ddb/db_break.cMon May 18 22:14:06 2015 (r283087) +++ head/sys/ddb/db_break.cMon 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. Yes, please do. Pedanticism aside, boolean types are extremely valuable because they document the intended use of the data. IMO the value in that far outweighs arguments about spelling and conversions and other whinging about things that work just fine. To sum it up, int is one of the vaguest things you can say in C, and boolean (in any reasonable spelling variation) is one of the clearest. -- Ian 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. Pedro. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r283088 - head/sys/ddb
On 05/19/15 08:45, John Baldwin wrote: On Tuesday, May 19, 2015 12:28:05 AM Pedro Giffuni wrote: 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. OK, I do understand the kernel wants to keep the C dialect somewhat limited, and adding stdbool.h doesn’t buy us any type safety here. I’ll revert the change (prob. tomorrow though). I will disagree with Bruce a bit and put my vote in for replacing boolean_t with bool where it is used. I do think that logically (if not strictly) your commit is a type mismatch as TRUE/FALSE is for boolean_t and true/false are for bool. I agree with Bruce that we probably don't want to use bool for system calls. However, I think using bool in the kernel itself is ok and that we should replace boolean_t with bool. I guess it boils down to the dilemma between modernity and common practice. OK, I know the current change can't stay as-is, and even Bruce admits that boolean_t is a mistake, so I think I will give the bool a try. Thanks for the feedback! Pedro. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r283088 - head/sys/ddb
Author: pfg Date: Mon May 18 22:27:46 2015 New Revision: 283088 URL: https://svnweb.freebsd.org/changeset/base/283088 Log: ddb: stop boolean screaming. TRUE -- true FALSE-- false Hinted by:NetBSD Modified: head/sys/ddb/db_break.c head/sys/ddb/db_command.c head/sys/ddb/db_examine.c head/sys/ddb/db_expr.c head/sys/ddb/db_input.c head/sys/ddb/db_main.c head/sys/ddb/db_ps.c head/sys/ddb/db_run.c head/sys/ddb/db_sym.c head/sys/ddb/db_textdump.c head/sys/ddb/db_watch.c head/sys/ddb/db_write_cmd.c 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; #ifndef BKPT_WRITE #defineBKPT_WRITE(addr, storage) \ do { \ - *storage = db_get_value(addr, BKPT_SIZE, FALSE);\ + *storage = db_get_value(addr, BKPT_SIZE, false);\ db_put_value(addr, BKPT_SIZE, BKPT_SET(*storage)); \ } while (0) #endif @@ -183,7 +183,7 @@ db_set_breakpoints(void) if (db_map_current(bkpt-map)) { BKPT_WRITE(bkpt-address, bkpt-bkpt_inst); } - db_breakpoints_inserted = TRUE; + db_breakpoints_inserted = true; } } @@ -200,7 +200,7 @@ db_clear_breakpoints(void) if (db_map_current(bkpt-map)) { BKPT_CLEAR(bkpt-address, bkpt-bkpt_inst); } - db_breakpoints_inserted = FALSE; + db_breakpoints_inserted = false; } } Modified: head/sys/ddb/db_command.c == --- head/sys/ddb/db_command.c Mon May 18 22:14:06 2015(r283087) +++ head/sys/ddb/db_command.c Mon May 18 22:27:46 2015(r283088) @@ -151,7 +151,7 @@ static struct command *db_last_command = * and '+' points to next line. * Otherwise: 'dot' points to next item, '..' points to last. */ -static boolean_t db_ed_style = TRUE; +static boolean_t db_ed_style = true; /* * Utility routine - discard tokens through end-of-line. @@ -327,7 +327,7 @@ db_command(struct command **last_cmdp, s int t; charmodif[TOK_STRING_SIZE]; db_expr_t addr, count; - boolean_t have_addr = FALSE; + boolean_t have_addr = false; int result; t = db_read_token(); @@ -335,7 +335,7 @@ db_command(struct command **last_cmdp, s /* empty line repeats last command, at 'next' */ cmd = *last_cmdp; addr = (db_expr_t)db_next; - have_addr = FALSE; + have_addr = false; count = 1; modif[0] = '\0'; } @@ -405,11 +405,11 @@ db_command(struct command **last_cmdp, s if (db_expression(addr)) { db_dot = (db_addr_t) addr; db_last_addr = db_dot; - have_addr = TRUE; + have_addr = true; } else { addr = (db_expr_t) db_dot; - have_addr = FALSE; + have_addr = false; } t = db_read_token(); if (t == tCOMMA) { @@ -530,7 +530,7 @@ db_dump(db_expr_t dummy, boolean_t dummy run \textdump unset\ first or \textdump dump\ for a textdump.\n); return; } - error = doadump(FALSE); + error = doadump(false); if (error) { db_printf(Cannot dump: ); switch (error) { Modified: head/sys/ddb/db_examine.c == --- head/sys/ddb/db_examine.c Mon May 18 22:14:06 2015(r283087) +++ head/sys/ddb/db_examine.c Mon May 18 22:27:46 2015(r283088) @@ -110,37 +110,37 @@ db_examine(db_addr_t addr, char *fmt, in width = size * 4; switch (c) { case 'r': /* signed, current radix */ - value = db_get_value(addr, size, TRUE); + value = db_get_value(addr, size, true); addr += size; db_printf(%+-*lr, width, (long)value); break; case 'x': /* unsigned hex */ -
Re: svn commit: r283088 - head/sys/ddb
On May 18, 2015, at 22:28, Pedro Giffuni p...@freebsd.org wrote: Il giorno 18/mag/2015, alle ore 23:34, Bruce Evans b...@optusnet.com.au ha scritto: 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. Actually, the NetBSD code uses bool. (I hate CVS, commits are not atomic.) 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? Unrelated fun: last year a student started adding support for CTF and pretty printing of the kernel structures. I think the NetBSD guys have been having fun with Lua. 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. OK, I do understand the kernel wants to keep the C dialect somewhat limited, and adding stdbool.h doesn’t buy us any type safety here. I’ll revert the change (prob. tomorrow though). Too bad. You could just convert bool to an enum, add a compile-time assert, and chase down all of the -Werrors with clang... ... Nevermind. Not fun :(.. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r283088 - head/sys/ddb
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-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r283088 - head/sys/ddb
Il giorno 18/mag/2015, alle ore 23:34, Bruce Evans b...@optusnet.com.au ha scritto: 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. Actually, the NetBSD code uses bool. (I hate CVS, commits are not atomic.) 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? Unrelated fun: last year a student started adding support for CTF and pretty printing of the kernel structures. I think the NetBSD guys have been having fun with Lua. Modified: head/sys/ddb/db_break.c == --- head/sys/ddb/db_break.cMon May 18 22:14:06 2015 (r283087) +++ head/sys/ddb/db_break.cMon 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. OK, I do understand the kernel wants to keep the C dialect somewhat limited, and adding stdbool.h doesn’t buy us any type safety here. I’ll revert the change (prob. tomorrow though). Pedro. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r283088 - head/sys/ddb
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. 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. 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_tdb_breakpoints_inserted = TRUE; +static boolean_tdb_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. 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. Pedro. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r283088 - head/sys/ddb
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. 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. 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. Bruce ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org