From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-84480-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 31779 invoked by alias); 17 Oct 2011 18:23:34 -0000
Received: (qmail 31770 invoked by uid 22791); 17 Oct 2011 18:23:33 -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 18:23:18 +0000
Received: from vapier.localnet (localhost [127.0.0.1])	by smtp.gentoo.org (Postfix) with ESMTP id 612691B4017;	Mon, 17 Oct 2011 18:23:17 +0000 (UTC)
From: Mike Frysinger <vapier@gentoo.org>
To: Joel Brobecker <brobecker@adacore.com>
Subject: Re: [PATCH] sim: dv-cfi: include stdbool.h
Date: Mon, 17 Oct 2011 20:27: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> <201110171306.34450.vapier@gentoo.org> <20111017172603.GY19246@adacore.com>
In-Reply-To: <20111017172603.GY19246@adacore.com>
MIME-Version: 1.0
Content-Type: Text/Plain;  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201110171423.17537.vapier@gentoo.org>
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2011-10/txt/msg00483.txt.bz2

On Monday 17 October 2011 13:26:03 Joel Brobecker wrote:
> > > What we should do is get rid of uses of true and false, and use the
> > > typical zero/nonzero values instead. I think that the blackfin header
> > > and code should be cleaned up accordingly as well.
> > 
> > ah, this would make me sad.  would a  configure check for stdbool.h be
> > acceptable ?
> 
> But what would you do if stdbool.h is not available? Wouldn't that
> complicate the code in the end?

#ifdef HAVE_STDBOOL_H
# include <stdbool.h>
#else
# define bool int
# define true 1
# define false 0
#endif

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.

if you really prefer to not have this, i understand.  but i find stdbool to be 
a useful addition ...
-mike