This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] sim: dv-cfi: include stdbool.h


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]