This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils 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 RFA] More stdbool.h fallout


Daniel Jacobowitz <drow@mvista.com> writes:

> On Fri, Feb 01, 2002 at 08:29:12PM -0500, DJ Delorie wrote:
> > 
> > > How about editing bfd.h (or one of its precursors like bfd-3.in)
> > > based on what autoconf finds?  Thus no ifdefing in the result,
> > > and thus we avoid the afeared losage.
> > 
> > That won't work if bfd.h is installed in an include directory shared
> > by many targets.
> 
> I don't think this is a problem... we do some configury into bfd.h, it
> is target-specific, it just can't depend on config.h because it can be
> included by programs with arbitrary contents of config.h.

Most of the configuration of bfd.h is target specific.  This is
reasonable, because libbfd is itself target specific.

The only current exception is the macros used to define the 64 bit
integer type used by the host compiler.  This is designed, perhaps
successfully, to be independent of the particular compiler, and to
depend only upon the host.  This is not completely unreasonable, as
libbfd is presumably in a host specific format.

Changing bfd.h to know whether stdbool.h exists, based on configury
tests, would make it compiler specific.  This doesn't sound ideal.  It
might break in an odd manner if somebody backs up to an earlier
version of the compiler.  It makes it difficult to distribute BFD as a
binary package, as it introduces an odd an nonobvious dependency on
the compiler version.


I personally have never cared for the fact that bfd.h defines such
commonly used terms as true, false, and boolean.  That was a mistake
made in the early days of BFD (or perhaps the mistake was that C did
not include such common concepts).  But it would certainly be a pain
to change bfd.h now.


One approach that would not solve the problem, but might finesse the
particular issues arising at the moment, would be to, instead of
having bfd.h define true and false as enum constants, to instead use
#define.  This could be done on the argument that bfd.h should mimic
stdbool.h.  It would dodge the problem of including both bfd.h and
stdbool.h, as it is permissible to #define a name to the same value
more than once.

That is:

#if defined (__GNUG__) && (__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 6))
#define TRUE_FALSE_ALREADY_DEFINED
#endif
#ifdef MPW
/* Pre-emptive strike - get the file with the enum.  */
#include <Types.h>
#define TRUE_FALSE_ALREADY_DEFINED
#endif /* MPW */
#ifndef TRUE_FALSE_ALREADY_DEFINED
#ifndef true
#define true 1
#endif
#ifndef false
#define false 0
#endif
#endif
/* Use enum names that will appear nowhere else.  */
typedef enum bfd_boolean {bfd_fffalse, bfd_tttrue} boolean;

Note that, unlike the old code, this never defines BFD_TRUE_FALSE.
Fortunately that does not appear to be used anywhere in the binutils
sources.

Note that this code continues to ignore the problem of the type named
`boolean'.  Presumably it hasn't caused serious difficulties yet,
although some day I am sure that it will.

Ian


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