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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.