From: York Sun <yorksun@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] Introduce a global bool type
Date: Tue, 8 Jan 2013 11:56:17 -0800 [thread overview]
Message-ID: <50EC79E1.1080802@freescale.com> (raw)
In-Reply-To: <20130108190715.D2D14202B69@gemini.denx.de>
On 01/08/2013 11:07 AM, Wolfgang Denk wrote:
> Dear Timur Tabi,
>
> In message <50EC5D29.1070408@freescale.com> you wrote:
>>
>>> _Bool has 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.
>
>>> 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) ...
>>
>> 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.
>
No disagree. How shall we close this? Will some change like below
acceptable?
diff --git a/include/linux/types.h b/include/linux/types.h
index 925ece7..f07ba41 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -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
next prev parent reply other threads:[~2013-01-08 19:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-07 22:10 [U-Boot] [PATCH] Introduce a global bool type York Sun
2013-01-07 22:29 ` Scott Wood
2013-01-07 22:32 ` [U-Boot] [u-boot-release] " Timur Tabi
2013-01-07 22:39 ` [U-Boot] " Wolfgang Denk
2013-01-07 22:50 ` Scott Wood
2013-01-07 22:54 ` Måns Rullgård
2013-01-08 6:25 ` Wolfgang Denk
2013-01-08 16:51 ` Tabi Timur-B04825
2013-01-08 17:49 ` Wolfgang Denk
2013-01-08 17:53 ` Timur Tabi
2013-01-08 19:07 ` Wolfgang Denk
2013-01-08 19:09 ` Timur Tabi
2013-01-08 19:56 ` York Sun [this message]
2013-01-08 21:39 ` Wolfgang Denk
2013-01-08 21:43 ` York Sun
2013-01-08 21:46 ` Scott Wood
2013-01-19 9:30 ` Albert ARIBAUD
2013-01-21 18:05 ` Scott Wood
2013-01-21 22:36 ` Måns Rullgård
2013-01-21 22:51 ` Scott Wood
2013-01-21 23:08 ` Måns Rullgård
2013-01-22 7:41 ` Albert ARIBAUD
2013-01-22 12:59 ` Måns Rullgård
2013-01-08 18:34 ` Bernhard Walle
2013-01-08 19:08 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50EC79E1.1080802@freescale.com \
--to=yorksun@freescale.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox