Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Joel Brobecker <brobecker@adacore.com>
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:58:00 -0000	[thread overview]
Message-ID: <201110171653.56749.vapier@gentoo.org> (raw)
In-Reply-To: <20111017202717.GB19246@adacore.com>

On Monday 17 October 2011 16:27:17 Joel Brobecker wrote:
> > #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.

do we have any "global" sim maintainers ?  either i'm reading sim/MAINTAINERS 
wrong, or we don't ...

i can migrate the dv-cfi code to use 0/1 to match the rest of the common/ tree, 
and because the "bool" usage is contained inside the one file.  np there.  but 
for bfin/, i'd like to keep stdbool.h usage for the arch port since the bool 
usage spreads across files.

this would also contain the breakage to anyone targeting Blackfin ports rather 
than anyone trying to use the sim.

> 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.

i don't think we can integrate the two.  gdb needs sim to complete first 
because gdb links against the resulting libsim.a.  so we can't have sim depend 
on any of the build targets under the gdb subdir.

> 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.

sure, if people are careful, 0/1 isn't an issue.  but if people were careful, 
we wouldn't need stdbool in the first place :).  i find it a comforting layer 
for sanity to be enforced in the language.
-mike


  reply	other threads:[~2011-10-17 20:54 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
2011-10-17 20:58           ` Mike Frysinger [this message]
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=201110171653.56749.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=toolchain-devel@blackfin.uclinux.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