From: Joel Brobecker <brobecker@adacore.com>
To: Mike Frysinger <vapier@gentoo.org>
Cc: gdb-patches@sourceware.org, toolchain-devel@blackfin.uclinux.org
Subject: Re: [PATCH] sim: dv-cfi: include stdbool.h
Date: Mon, 17 Oct 2011 20:54:00 -0000 [thread overview]
Message-ID: <20111017202717.GB19246@adacore.com> (raw)
In-Reply-To: <201110171423.17537.vapier@gentoo.org>
> #ifdef HAVE_STDBOOL_H
> # include <stdbool.h>
> #else
> # define bool int
> # define true 1
> # define false 0
> #endif
I don't know what the others feel about this, I'm always wary of
this, but maybe I'm too paranoid. I remember using these sorts of
defines, and getting into portability issues, but that was a very
long time ago, and I don't remember the details. Perhaps I didn't
do something right, or it's now OBE.
In the end, I am a GDB maintainer, not a sim maintainer, so I can
only express an opinion. If the above doesn't break any other
platforms, I suppose that's good enough.
I think that the best compromise, if you really want to "true" and/or
"false", is to probably start using gnulib in the sim code as well.
I just don't know offhand how easy it would be to integrate that
with GDB's use of gnulib. But it'd allow you to include stdbool.h
unconditionally, knowing that gnulib would provide it if the system
doesn't already.
Anyways, I'll let you decide on this particular topic, I don't think
it's a critical piece of the sim code.
> when reading the code, i find true/false to be more natural than 0/1.
> especially when 0/1 return values are not consistent across code
> bases.
Then just be carefule that "if COND == true" is no longer the same as
"if COND". I just find it more robust to think that truth is equivalent
to nonzero.
--
Joel
next prev parent reply other threads:[~2011-10-17 20:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-11 19:50 Mike Frysinger
2011-09-29 2:02 ` Mike Frysinger
2011-10-10 2:42 ` Mike Frysinger
2011-10-17 16:57 ` Joel Brobecker
2011-10-17 17:08 ` Mike Frysinger
2011-10-17 17:28 ` Joel Brobecker
2011-10-17 20:27 ` Mike Frysinger
2011-10-17 20:54 ` Joel Brobecker [this message]
2011-10-17 20:58 ` Mike Frysinger
2011-10-17 21:11 ` Tom Tromey
2011-10-18 0:16 ` Joel Brobecker
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=20111017202717.GB19246@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=toolchain-devel@blackfin.uclinux.org \
--cc=vapier@gentoo.org \
/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