From: Timur Tabi <b04825@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] Introduce a global bool type
Date: Tue, 8 Jan 2013 11:53:45 -0600 [thread overview]
Message-ID: <50EC5D29.1070408@freescale.com> (raw)
In-Reply-To: <20130108174920.BAB22202B69@gemini.denx.de>
Wolfgang Denk wrote:
> Dear Tabi Timur-B04825,
>
> In message <6AE080B68D46FC4BA2D2769E68D765B70820541F@039-SN2MPN1-023.039d.mgd.msft.net> you wrote:
>>>
>>> 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 was introduced in C99, which is over 12 years old.
> 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) ...
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.
--
Timur Tabi
Linux kernel developer at Freescale
next prev parent reply other threads:[~2013-01-08 17:53 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 [this message]
2013-01-08 19:07 ` Wolfgang Denk
2013-01-08 19:09 ` Timur Tabi
2013-01-08 19:56 ` York Sun
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=50EC5D29.1070408@freescale.com \
--to=b04825@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