From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9878 invoked by alias); 17 Oct 2011 20:27:44 -0000 Received: (qmail 9867 invoked by uid 22791); 17 Oct 2011 20:27:42 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 17 Oct 2011 20:27:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0F5F42BB267; Mon, 17 Oct 2011 16:27:21 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4PRl+tv5cYVa; Mon, 17 Oct 2011 16:27:20 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id D813F2BB266; Mon, 17 Oct 2011 16:27:20 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 9BD19145615; Mon, 17 Oct 2011 16:27:17 -0400 (EDT) Date: Mon, 17 Oct 2011 20:54:00 -0000 From: Joel Brobecker To: Mike Frysinger Cc: gdb-patches@sourceware.org, toolchain-devel@blackfin.uclinux.org Subject: Re: [PATCH] sim: dv-cfi: include stdbool.h Message-ID: <20111017202717.GB19246@adacore.com> References: <1310410693-20883-1-git-send-email-vapier@gentoo.org> <201110171306.34450.vapier@gentoo.org> <20111017172603.GY19246@adacore.com> <201110171423.17537.vapier@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110171423.17537.vapier@gentoo.org> User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00484.txt.bz2 > #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. 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