From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11515 invoked by alias); 17 Oct 2011 20:54:18 -0000 Received: (qmail 11500 invoked by uid 22791); 17 Oct 2011 20:54:17 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_TD X-Spam-Check-By: sourceware.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 17 Oct 2011 20:53:57 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 71D531B4017; Mon, 17 Oct 2011 20:53:56 +0000 (UTC) From: Mike Frysinger To: Joel Brobecker Subject: Re: [PATCH] sim: dv-cfi: include stdbool.h Date: Mon, 17 Oct 2011 20:58:00 -0000 User-Agent: KMail/1.13.7 (Linux/3.1.0-rc4; KDE/4.6.5; x86_64; ; ) Cc: gdb-patches@sourceware.org, toolchain-devel@blackfin.uclinux.org References: <1310410693-20883-1-git-send-email-vapier@gentoo.org> <201110171423.17537.vapier@gentoo.org> <20111017202717.GB19246@adacore.com> In-Reply-To: <20111017202717.GB19246@adacore.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110171653.56749.vapier@gentoo.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00485.txt.bz2 On Monday 17 October 2011 16:27:17 Joel Brobecker wrote: > > #ifdef HAVE_STDBOOL_H > > # include > > #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