Introduce a global bool type
Subsystems (4)
PATCH 1/1 Introduce a global bool type
'bool' is defined in random places. This patch consolidates them into a single typedef.
--- arch/blackfin/include/asm/posix_types.h | 3 --- board/Marvell/include/core.h | 5 ----- drivers/mtd/nand/mxc_nand.c | 2 -- drivers/usb/musb-new/linux-compat.h | 2 -- include/galileo/core.h | 5 ----- include/linux/types.h | 2 ++ include/xyzModem.h | 5 ----- 7 files changed, 2 insertions(+), 22 deletions(-)
arch/blackfin/include/asm/posix_types.h +0 -3
@@ -61,9 +61,6 @@ typedef unsigned int __kernel_gid32_t;typedef unsigned short __kernel_old_uid_t ;typedef unsigned short __kernel_old_gid_t ; -#define BOOL_WAS_DEFINED -typedef enum { false =0 , true =1 }bool ; -#ifdef __GNUC__typedef long long __kernel_loff_t ;#endif
board/Marvell/include/core.h +0 -5
@@ -91,11 +91,6 @@ extern unsigned int INTERNAL_REG_BASE_ADDR;#define _1G 0x40000000#define _2G 0x80000000 -#ifndef BOOL_WAS_DEFINED -#define BOOL_WAS_DEFINED -typedef enum _bool {false,true}bool ; -#endif -/* Little to Big endian conversion macros */ #ifdef LE /* Little Endian */
drivers/mtd/nand/mxc_nand.c +0 -2
@@ -29,8 +29,6 @@#define DRIVER_NAME "mxc_nand" -typedef enum {false, true}bool ; -struct mxc_nand_host {struct mtd_info mtd;struct nand_chip *nand;
drivers/usb/musb-new/linux-compat.h +0 -2
@@ -12,8 +12,6 @@#define __iomem#define __deprecated -typedef enum { false =0 , true =1 }bool ; -struct unused {};typedef struct unused unused_t ;
include/galileo/core.h +0 -5
@@ -110,11 +110,6 @@ extern unsigned int INTERNAL_REG_BASE_ADDR;#define _1G 0x40000000#define _2G 0x80000000 -#ifndef BOOL_WAS_DEFINED -#define BOOL_WAS_DEFINED -typedef enum _bool {false,true}bool ; -#endif -/* Little to Big endian conversion macros */ #ifdef LE /* Little Endian */
include/linux/types.h +2 -0
@@ -113,6 +113,8 @@ typedef __u64 u_int64_t;typedef __s64 int64_t ;#endif +typedef _Bool bool ; +#endif /* __KERNEL_STRICT_NAMES */ /*
include/xyzModem.h +0 -5
@@ -97,11 +97,6 @@ typedef struct {#endif } connection_info_t; -#ifndef BOOL_WAS_DEFINED -#define BOOL_WAS_DEFINED -typedef unsigned int bool ; -#endif -#define false 0#define true 1
Signature · 1 line
1.7.9.5
PATCH 1/1 Introduce a global bool type
Quoted 18 lines · York Sun
include/linux/types.h +2
-0@@ -113,6 +113,8 @@ typedef __u64 u_int64_t;typedef __s64 int64_t ;#endif +typedef _Bool bool ; +#endif /* __KERNEL_STRICT_NAMES */ /* include/xyzModem.h +0
-0
include/xyzModem.h typedef struct { · line 101
Quoted 10 lines
include/xyzModem.h +0
-5@@ -97,11 +97,6 @@ typedef struct {#endif } connection_info_t; -#ifndef BOOL_WAS_DEFINED -#define BOOL_WAS_DEFINED -typedef unsigned int bool ; -#endif -#define false 0#define true 1
Please also move the definition of true/false into a common header.
-Scott
PATCH 1/1 Introduce a global bool type
In reply to York SunQuoted 2 lines · York Sun
'bool' is defined in random places. This patch consolidates them into a single typedef.
... and defines 'bool' in a completely different way, so it doesn't just "consolidate" the definitions.
I would add a comment that says that _Bool was introduced in C99, so it should be safe to use this new definition instead of a hand-coded enum.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
PATCH 1/1 Introduce a global bool type
In reply to York SunDear York Sun,
Quoted 2 lines · In message <[email protected]> you wrote:
'bool' is defined in random places. This patch consolidates them into a single typedef.
Has this been actually compile tested?
...
include/linux/types.h typedef __u64 u_int64_t; · line 116
Quoted 7 lines
include/linux/types.h +1
-0@@ -113,6 +113,8 @@ typedef __u64 u_int64_t;typedef __s64 int64_t ;#endif +typedef _Bool bool ;
And what exactly would "_Bool" be?
...
include/xyzModem.h typedef struct { · line 101
Quoted 13 lines
include/xyzModem.h +0
-5@@ -97,11 +97,6 @@ typedef struct {#endif } connection_info_t; -#ifndef BOOL_WAS_DEFINED -#define BOOL_WAS_DEFINED -typedef unsigned int bool ; -#endif -#define false 0#define true 1
And don't these remaining definitions of "false" and "true" cause nasty build errors somewhere?
This seems broken to me. Can we rather try8 and get rid of all this "bool" stuff instead? It's just obfuscating the code...
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Perl itself is usually pretty good about telling you what you shouldn't do. :-) - Larry Wall in <[email protected]>
PATCH 1/1 Introduce a global bool type
Quoted 17 lines · Wolfgang Denk
Dear York Sun,
In message <[email protected]>
Quoted 1 line · you
'bool' is defined in random places. This patch consolidates them
into a
Quoted 1 line
single typedef.
Has this been actually compile tested?
...
Quoted 6 lines
include/linux/types.h +0
-0@@ -113,6 +113,8 @@ typedef __u64 u_int64_t;typedef __s64 int64_t ;#endif
Quoted 3 lines
include/linux/types.h typedef __u64 u_int64_t; · line 116
Quoted 1 line
include/linux/types.h +1
-0+typedef _Bool bool ;And what exactly would "
_Bool" be?
It's a standard C99 type (as is bool, but _Bool comes directly from the compiler rather than from headers).
Quoted 7 lines
...
Quoted 6 lines
include/xyzModem.h +0
-0@@ -97,11 +97,6 @@ typedef struct {#endif } connection_info_t;
Quoted 10 lines
include/xyzModem.h typedef struct { · line 101
Quoted 7 lines
include/xyzModem.h +0
-5-#ifndef BOOL_WAS_DEFINED -#define BOOL_WAS_DEFINED -typedef unsigned int bool ; -#endif -#define false 0#define true 1And don't these remaining definitions of "false" and "true" cause nasty build errors somewhere?
Yes, the definition of true/false needs to move along with the definition of bool.
Quoted 2 lines
This seems broken to me. Can we rather try8 and get rid of all this "bool" stuff instead? It's just obfuscating the code...
That's obviously a matter of opinion (I think "bool" is clearer than "int"), but I'd like to point out that Linux's use of bool has been growing, and U-Boot often borrows code from Linux...
Also, FWIW the compiler will generally allocate only one byte for a built-in boolean, so there is a minor run-time benefit in some situations.
-Scott
PATCH 1/1 Introduce a global bool type
In reply to Wolfgang DenkQuoted 15 lines · Wolfgang Denk
Dear York Sun,
Quoted 2 lines · In message <[email protected]> you wrote:
'bool' is defined in random places. This patch consolidates them into a single typedef.
Has this been actually compile tested?
...
Quoted 6 lines
include/linux/types.h +0
-0@@ -113,6 +113,8 @@ typedef __u64 u_int64_t;typedef __s64 int64_t ;#endif
Quoted 3 lines
include/linux/types.h typedef __u64 u_int64_t; · line 116
Quoted 1 line
include/linux/types.h +1
-0+typedef _Bool bool ;And what exactly would "
_Bool" be?
_Bool is a C99 type (though I fail to imagine why). If using this, one might as well use the C99 header stdbool.h providing macros for 'bool', 'true' and 'false' instead of this.
Quoted 2 lines
Can we rather try and get rid of all this "bool" stuff instead? It's just obfuscating the code...
Indeed.
Signature · 2 lines
M?ns Rullg?rd mans at mansr.com
PATCH 1/1 Introduce a global bool type
Dear M?ns Rullg?rd,
Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 4 lines
Quoted 2 lines
+typedef
_Boolbool;And what exactly would "
_Bool" be?
_Boolis a C99 type (though I fail to imagine why). If using this, one might as well use the C99 headerstdbool.hproviding macros for 'bool', 'true' and 'false' instead of this.
Agreed - if we should really stick with that, that that's the way to go.
Quoted 4 lines
Quoted 2 lines
Can we rather try and get rid of all this "bool" stuff instead? It's just obfuscating the code...
Indeed.
Thanks.
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Save energy: Drive a smaller shell.
PATCH 1/1 Introduce a global bool type
In reply to Wolfgang DenkQuoted 3 lines · Wolfgang Denk
This seems broken to me. Can we rather try8 and get rid of all this "bool" stuff instead? It's just obfuscating the code...
Like Scott said, we sometimes copy code from Linux that uses 'bool', so it's simpler if we just retain this commonly-used type. If it's part of the language, how is it obfuscating? Maybe the Linux developers should have used _Bool instead of bool, but they didn't, and so here we are.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
PATCH 1/1 Introduce a global bool type
Dear Tabi Timur-B04825,
Quoted 7 lines · In message <6AE080B68D46FC4BA2D2769E68D765B70820541F@039-SN2MPN1-023.039d.mgd.m…
Quoted 3 lines
This seems broken to me. Can we rather try8 and get rid of all this "bool" stuff instead? It's just obfuscating the code...
Like Scott said, we sometimes copy code from Linux that uses 'bool', so it's simpler if we just retain this commonly-used type. If it's part of the language, how is it obfuscating? Maybe the Linux
_Bool has been introduced very late to any C standard, and you can still see this from the ugly, unnatural name.
It is my personal firm conviction that the people pushed it were not the ones who have been using C right from the beginning, say from the times of Unix v6 or so.
IMHO it is much better to rely on '0' meaning "false" and anything else meaning "true" instead of insisting on one specific value of "true". Yes, people claim the code is easier to read and understand, but these are the same people who claim drop-down menues are easier to work wit than a CLI. And I've seen more than one case where bugs were caused by using "proper bool types" like this:
i = 0; j = 0; k = 2; if ((i | j | k) == true) ...
Quoted 2 lines
developers should have used
_Boolinstead of bool, but they didn't, and so here we are.
Well, I raised my concerns, but I do not intend to formally NAK it. In any case, I insist on using the standard header file.
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Lispers are among the best grads of the Sweep-It-Under-Someone- Else's-Carpet School of Simulated Simplicity. [Was that sufficiently incendiary? :-)] - Larry Wall in <[email protected]
PATCH 1/1 Introduce a global bool type
Quoted 8 lines · Wolfgang Denk
Dear Tabi Timur-B04825,
Quoted 5 lines · In message <6AE080B68D46FC4BA2D2769E68D765B70820541F@039-SN2MPN1-023.039d.mgd.m…
Quoted 3 lines
This seems broken to me. Can we rather try8 and get rid of all this "bool" stuff instead? It's just obfuscating the code...
Quoted 6 lines
Quoted 3 lines
Like Scott said, we sometimes copy code from Linux that uses 'bool', so it's simpler if we just retain this commonly-used type. If it's part of the language, how is it obfuscating? Maybe the Linux
_Boolhas been introduced very late to any C standard, and you can still see this from the ugly, unnatural name.
It was introduced in C99, which is over 12 years old.
Quoted 11 lines
It is my personal firm conviction that the people pushed it were not the ones who have been using C right from the beginning, say from the times of Unix v6 or so.
IMHO it is much better to rely on '0' meaning "false" and anything else meaning "true" instead of insisting on one specific value of "true". Yes, people claim the code is easier to read and understand, but these are the same people who claim drop-down menues are easier to work wit than a CLI. And I've seen more than one case where bugs were caused by using "proper bool types" like this:
Quoted 5 lines
i = 0; j = 0; k = 2; if ((i | j | k) == true) ...
Ok, but this is just wrong. i, j, and k are not boolean types, so they should not be compared with 'true' or 'false'. I don't think you'll find any disagreement with that.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
PATCH 1/1 Introduce a global bool type
Dear Timur Tabi,
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 3 lines
_Boolhas been introduced very late to any C standard, and you can still see this from the ugly, unnatural name.It was introduced in C99, which is over 12 years old.
And how old is C? I think the "official" announcment was 1972, so
that's more than twice as long without that addition.
Quoted 7 lines
Quoted 7 lines
work wit than a CLI. And I've seen more than one case where bugs were caused by using "proper bool types" like this:
i = 0; j = 0; k = 2;
Quoted 5 lines
Quoted 1 line
if ((i | j | k) == true) ...Ok, but this is just wrong. i, j, and k are not boolean types, so they should not be compared with 'true' or 'false'. I don't think you'll find any disagreement with that.
You are right. And I wrote that it's a bug. But this is what you can easily get from using boolean types. This is example has not been invented by me. I don't even claim that this was good programming style - all I want to say is that from what I have seen the boolean types are not a panacea; they cause new problems as well.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de A modem is a baudy house.
PATCH 1/1 Introduce a global bool type
Quoted 5 lines · Wolfgang Denk
You are right. And I wrote that it's a bug. But this is what you can easily get from using boolean types. This is example has not been invented by me. I don't even claim that this was good programming style - all I want to say is that from what I have seen the boolean types are not a panacea; they cause new problems as well.
I don't disagree with any of that, but I don't see what your point is. Every time you use a new feature, there are also new ways to use it incorrectly. By your logic, we should use no new features of the C language that were invented in the past 20 years.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
PATCH 1/1 Introduce a global bool type
In reply to Wolfgang DenkQuoted 25 lines · Wolfgang Denk
Dear Timur Tabi,
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 3 lines
_Boolhas been introduced very late to any C standard, and you can still see this from the ugly, unnatural name.It was introduced in C99, which is over 12 years old.
And how old is C? I think the "official" announcment was 1972, so
that's more than twice as long without that addition.Quoted 7 lines
Quoted 7 lines
work wit than a CLI. And I've seen more than one case where bugs were caused by using "proper bool types" like this:
i = 0; j = 0; k = 2;Quoted 5 lines
Quoted 1 line
if ((i | j | k) == true) ...Ok, but this is just wrong. i, j, and k are not boolean types, so they should not be compared with 'true' or 'false'. I don't think you'll find any disagreement with that.
Quoted 6 lines
You are right. And I wrote that it's a bug. But this is what you can easily get from using boolean types. This is example has not been invented by me. I don't even claim that this was good programming style - all I want to say is that from what I have seen the boolean types are not a panacea; they cause new problems as well.
No disagree. How shall we close this? Will some change like below acceptable?
include/linux/types.h +1 -4
@@ -7,6 +7,7 @@#include <linux/posix_types.h> #include <asm/types.h> +#include <stdbool.h> #ifndef __KERNEL_STRICT_NAMES
@@ -113,10 +114,6 @@ typedef __u64 u_int64_t;typedef __s64 int64_t ;#endif -typedef _Bool bool ; -#define false 0 -#define true 1 -#endif /* __KERNEL_STRICT_NAMES */ /*
York
PATCH 1/1 Introduce a global bool type
Dear York Sun,
include/linux/types.h line 10
Quoted 13 lines · In message <[email protected]> you wrote:
No disagree. How shall we close this? Will some change like below acceptable?
include/linux/types.h +1
-0@@ -7,6 +7,7 @@#include <linux/posix_types.h> #include <asm/types.h> +#include <stdbool.h>
Yes, but it needs to be tested that this is working for at least the most popular tool chains, including when using USE_PRIVATE_LIBGCC.
include/linux/types.h typedef __u64 u_int64_t; · line 119
Quoted 10 lines
include/linux/types.h +0
-4#ifndef __KERNEL_STRICT_NAMES@@ -113,10 +114,6 @@ typedef __u64 u_int64_t;typedef __s64 int64_t ;#endif -typedef _Bool bool ; -#define false 0 -#define true 1 -
Yes, but similar removals are needed in a nomber of other header files as well.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Hindsight is an exact science.
PATCH 1/1 Introduce a global bool type
Quoted 13 lines · Wolfgang Denk
Dear York Sun,
Quoted 10 lines · In message <[email protected]> you wrote:
No disagree. How shall we close this? Will some change like below acceptable?
include/linux/types.h +0
-0@@ -7,6 +7,7 @@
Quoted 6 lines
include/linux/types.h line 10
Quoted 3 lines
include/linux/types.h +1
-0#include <linux/posix_types.h> #include <asm/types.h> +#include <stdbool.h> Yes, but it needs to be tested that this is working for at least the most popular tool chains, including when using
USE_PRIVATE_LIBGCC.
Who can help here? I don't have the setup for other than powerpc.
Quoted 7 lines
Quoted 7 lines
include/linux/types.h +0
-0#ifndef __KERNEL_STRICT_NAMES@@ -113,10 +114,6 @@ typedef __u64 u_int64_t;typedef __s64 int64_t ;#endif
Quoted 8 lines
include/linux/types.h typedef __u64 u_int64_t; · line 119
Quoted 4 lines
include/linux/types.h +0
-4-typedef _Bool bool ; -#define false 0 -#define true 1 -Yes, but similar removals are needed in a nomber of other header files as well.
Yes. I have those in my local tree.
York
PATCH 1/1 Introduce a global bool type
Quoted 14 lines · York Sun
Quoted 13 lines · Wolfgang Denk
Dear York Sun,
Quoted 10 lines · In message <[email protected]> you wrote:
No disagree. How shall we close this? Will some change like below acceptable?
include/linux/types.h +0
-0@@ -7,6 +7,7 @@
Quoted 8 lines
Quoted 6 lines
include/linux/types.h line 10
Quoted 3 lines
include/linux/types.h +1
-0#include <linux/posix_types.h> #include <asm/types.h> +#include <stdbool.h> Yes, but it needs to be tested that this is working for at least the most popular tool chains, including when using
USE_PRIVATE_LIBGCC.Who can help here? I don't have the setup for other than powerpc.
http://marc.info/?l=u-boot&m=132164771013203&w=1
-Scott
PATCH 1/1 Introduce a global bool type
In reply to Wolfgang DenkHi Wolfgang,
My 2 EUR cents:
On Tue, 08 Jan 2013 20:07:15 +0100, Wolfgang Denk <[email protected]> wrote:
(sorry for the late chiming in)
Quoted 25 lines
Dear Timur Tabi,
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 3 lines
_Boolhas been introduced very late to any C standard, and you can still see this from the ugly, unnatural name.It was introduced in C99, which is over 12 years old.
And how old is C? I think the "official" announcment was 1972, so
that's more than twice as long without that addition.Quoted 7 lines
Quoted 7 lines
work wit than a CLI. And I've seen more than one case where bugs were caused by using "proper bool types" like this:
i = 0; j = 0; k = 2;Quoted 5 lines
Quoted 1 line
if ((i | j | k) == true) ...Ok, but this is just wrong. i, j, and k are not boolean types, so they should not be compared with 'true' or 'false'. I don't think you'll find any disagreement with that.
Quoted 5 lines
You are right. And I wrote that it's a bug. But this is what you can easily get from using boolean types. This is example has not been invented by me. I don't even claim that this was good programming style - all I want to say is that from what I have seen the boolean types are not a panacea; they cause new problems as well.
Ok, so there are three things in Wolfgang's example: a lax boolean (set to 2), a mix-up between bitwise and boolean operators (which a compiler may or may not detect or at least flag as suspicious), and finally a comparison of the lax boolean (2) with a strict boolean (true, equal to 1) which will fail.
I guess we're all aware of this type of problem. To avoid it, I personally try to apply the Postel principle here: be conservative in what you do, thus only produce strict boolean objects, and be liberal in what you get, i.e. consider all boolean expressions to be lax.
This means that as far as coding practice is concerned, I tend to favor the style set forth in the next three lines, where I always compute booleans with true and false and boolean operators, but test them 'zero/nonzero':
/* what I favor */
clk_is_enabled = ((reg_val >> 9) & 1) ? true: false;
ip_is_enabled = clk_is_enabled && pwd_is_enabled;
if (clk_is_enabled) { ...rather than assigning them 'zero/nonzero', or using bitwise ops on booleans, or testing against boolean constants (although I concede that the first line below wins over its counterpart above as far as concision is concerned).
/* what I don't favor */
clk_is_enabled = ((register >> 9) & 1);
ip_is_enabled = clk_is_enabled & pwd_is_enabled;
if (clk_is_enabled == true) { ...This way I am sure to evaluate any nonzero value as 'true', so lax code can safely pass me lax booleans, and I am sure that my booleans equal 1 when true, so I always pass strict booleans to strict code.
Oh, and I also try to wisely name boolean objects, so that they read out loud as a boolean statement, e.g. "clock is enabled", but this is a bit (more) beside the point.
Quoted 3 lines
Best regards,
Wolfgang Denk
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 Introduce a global bool type
Quoted 9 lines · Albert ARIBAUD
/* what I favor */ clk_is_enabled = ((reg_val >> 9) & 1) ? true: false; ip_is_enabled = clk_is_enabled && pwd_is_enabled; if (clk_is_enabled) { ...rather than assigning them 'zero/nonzero', or using bitwise ops on booleans, or testing against boolean constants (although I concede that the first line below wins over its counterpart above as far as concision is concerned).
Conciseness can be improved with "!!((reg_val >> 9) & 1)".
-Scott
PATCH 1/1 Introduce a global bool type
Quoted 6 lines · Scott Wood
Quoted 5 lines · Albert ARIBAUD
/* what I favor */ clk_is_enabled = ((reg_val >> 9) & 1) ? true: false; ip_is_enabled = clk_is_enabled && pwd_is_enabled; if (clk_is_enabled) { ...
Quoted 6 lines
Quoted 4 lines
rather than assigning them 'zero/nonzero', or using bitwise ops on booleans, or testing against boolean constants (although I concede that the first line below wins over its counterpart above as far as concision is concerned).
Conciseness can be improved with "!!((reg_val >> 9) & 1)".
x & 1 is already either zero or one. Any further operations are nothing but obfuscation.
Signature · 2 lines
M?ns Rullg?rd mans at mansr.com
PATCH 1/1 Introduce a global bool type
Quoted 13 lines · M?ns Rullg?rd
Quoted 11 lines · Scott Wood
Quoted 9 lines · Albert ARIBAUD
/* what I favor */ clk_is_enabled = ((reg_val >> 9) & 1) ? true: false; ip_is_enabled = clk_is_enabled && pwd_is_enabled; if (clk_is_enabled) { ...rather than assigning them 'zero/nonzero', or using bitwise ops on booleans, or testing against boolean constants (although I concede that the first line below wins over its counterpart above as far as concision is concerned).
Quoted 5 lines
Quoted 1 line
Conciseness can be improved with "!!((reg_val >> 9) & 1)".
x & 1 is already either zero or one. Any further operations are nothing
but obfuscation.
The point is to avoid depending on the actual integer values of the boolean type, and make the code more robust against changes (e.g. someone later comes along and says "hmm, that 1 should be a 3 because we care about that other register bit as well" without noticing that it's being assigned to a boolean.
-Scott
PATCH 1/1 Introduce a global bool type
Quoted 14 lines · Scott Wood
Quoted 13 lines · M?ns Rullg?rd
Quoted 11 lines · Scott Wood
Quoted 9 lines · Albert ARIBAUD
/* what I favor */ clk_is_enabled = ((reg_val >> 9) & 1) ? true: false; ip_is_enabled = clk_is_enabled && pwd_is_enabled; if (clk_is_enabled) { ...rather than assigning them 'zero/nonzero', or using bitwise ops on booleans, or testing against boolean constants (although I concede that the first line below wins over its counterpart above as far as concision is concerned).
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Conciseness can be improved with "!!((reg_val >> 9) & 1)".
x & 1 is already either zero or one. Any further operations are nothing
but obfuscation.The point is to avoid depending on the actual integer values of the boolean type,
Boolean expressions are defined to have a value of zero or one, and the _Bool type (may it burn in hell) must be able to represent those values.
Quoted 4 lines
and make the code more robust against changes (e.g. someone later comes along and says "hmm, that 1 should be a 3 because we care about that other register bit as well" without noticing that it's being assigned to a boolean.
If you stayed away from the silly _Bool type that wouldn't be a problem, as long as any uses of the value treat all non-zero values equally, i.e. only use it in a boolean context and not compare against explicit values or perform arithmetic or bitwise logic operations on it.
In other words, boolifying on use rather than on assignment is generally safer and usually at least as efficient.
Signature · 2 lines
M?ns Rullg?rd mans at mansr.com
PATCH 1/1 Introduce a global bool type
Hi M?ns,
Quoted 2 lines
In other words, boolifying on use rather than on assignment is generally safer and usually at least as efficient.
Except when assigning a C = A & B where A and B happen to have no common bit set. Which is why I think 'boolifying' as soon as possible -- on assignment -- is way safer than on use.
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 Introduce a global bool type
Quoted 8 lines · Albert ARIBAUD
Hi M?ns,
Quoted 2 lines
In other words, boolifying on use rather than on assignment is generally safer and usually at least as efficient.
Except when assigning a C = A & B where A and B happen to have no common bit set. Which is why I think 'boolifying' as soon as possible -- on assignment -- is way safer than on use.
But that's not a boolean context. You should use A && B.
The thing is, when using a value, you know if you need a boolean, but not necessarily (easily) how the value was assigned. Conversely, when assigning a value, you do not know how it will be used. By always boolifying on use, you remove the need to keep track of which values are "true" booleans and which ones are arbitrary values (or even pointers) you happen to be using in a boolean fashion.
Signature · 2 lines
M?ns Rullg?rd mans at mansr.com
PATCH 1/1 Introduce a global bool type
In reply to Wolfgang DenkQuoted 11 lines · Wolfgang Denk
Quoted 7 lines · In message <6AE080B68D46FC4BA2D2769E68D765B70820541F@039-SN2MPN1-023.039d.mgd.m…
Quoted 3 lines
This seems broken to me. Can we rather try8 and get rid of all this "bool" stuff instead? It's just obfuscating the code...
Like Scott said, we sometimes copy code from Linux that uses 'bool', so it's simpler if we just retain this commonly-used type. If it's part of the language, how is it obfuscating? Maybe the Linux
_Boolhas been introduced very late to any C standard, and you can still see this from the ugly, unnatural name.
But C99 (well, that's 12 years now!) also includes <stdbool.h> that defines 'bool', 'true' and 'false'.
Regards,
Bernhard
PATCH 1/1 Introduce a global bool type
Dear Bernhard Walle,
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines
_Boolhas been introduced very late to any C standard, and you can still see this from the ugly, unnatural name.But C99 (well, that's 12 years now!) also includes <
stdbool.h> that defines 'bool', 'true' and 'false'.
That's strange - you make the same mistake as Timur.
For me 2013 - 1999 != 12 :-P
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de : ... and it's got weird formatting - Notepad, Write, Works 3 can't : decipher it, and it's too big to go in DOS Edit. Help! Install an operating system. :-) -- Tom Christiansen