From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13543 invoked by alias); 8 Feb 2002 23:37:26 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13454 invoked from network); 8 Feb 2002 23:37:25 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 8 Feb 2002 23:37:25 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16ZKZz-0001M9-00; Fri, 08 Feb 2002 18:37:19 -0500 Date: Fri, 08 Feb 2002 15:37:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: Remove true/false from GDB .... Message-ID: <20020208183719.A5159@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <3C645FE0.30201@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C645FE0.30201@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00156.txt.bz2 On Fri, Feb 08, 2002 at 06:31:44PM -0500, Andrew Cagney wrote: > Hello, > > This is fallout from the recent problem. > > "bfd.h" was providing ``true'' and ``false'' as convenience > enums/macros/... They unfortunatly clash with systems that provide > (a header in c99?) and even some systems that don't. The > relevant code block is: > > /* I'm sure this is going to break something and someone is going to > force me to change it. */ > /* typedef enum boolean {false, true} boolean; */ > /* Yup, SVR4 has a "typedef enum boolean" in -fnf */ > /* It gets worse if the host also defines a true/false enum... -sts */ > /* And even worse if your compiler has built-in boolean types... -law */ > /* And even worse if your compiler provides a stdbool.h that conflicts > with these definitions... gcc 2.95 and later do. If so, it must > be included first. -drow */ > #if ... > ... many valiant attemts to define true and false ... > #else > /* Use enum names that will appear nowhere else. */ > typedef enum bfd_boolean {bfd_fffalse, bfd_tttrue} boolean; > #endif > > In short, bfd.h should never have been polluting the name space with > ``true'' and ``false''. > > So the proposal is for "bfd.h" to remove all the above code and instead > just define: > > typedef int bfd_boolean; > > i.e. 0 is false, non-zero is true, just like C intended :-) > > Problem is, some blocks of GDB make use of ``true'' and ``false'' and > they will need to be changed. Two possabilities come to mind: > > #include "gdb_stdbool.h" > which would wrap > > zap ``true'' and ``false'' > > I've strong preferences for the latter. I think BFD serves as a very > compelling example of what not to do :-) > > thoughts? Strong preference for the latter here too. We should not attempt to use true/false in C. You never know where they're going to come from - or not come from. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer