Re: Not compilable with all warnings enabled "... throws different exceptions" (Bug in GNU Binutils)

[Ian Lance Taylor]

Marc Waeckerlin <address@hidden> writes:

> Am Donnerstag, 26. August 2004 16.22 schrieb Ian Lance Taylor  <Ian Lance 
> Taylor <address@hidden>> unter "Re: Not compilable with all warnings 
> enabled "... throws different exceptions" (Bug in GNU Binutils)":
> > What we don't do is compile everything with g++.  The binutils are
> > written in C and most of us program in C.
> 
> I understand that you mostly program in C, but some are using your libraries 
> from C++. It wouldn't bee to much work to rerun all tests that passed with 
> gcc also with g++.

No, because we can't build the binutils with a C++ compiler.  We test
the header files by building the binutils on various hosts, with
warnings enabled.  That can not be done with a C++ compiler.

Of course we could write some tests for C++ code which uses the header
files.  And we could add those to the testsuite.  And maybe somebody
will do that, and contribute them.

In any case, the way to get us to do something is not to start of by
saying that code has such "bad quality."

> > Note that libiberty.h is written to check various configure macros
> > when including declarations such as the ones you are complaining
> > about.  You can define those configure macros yourself.  I would
> > certainly be open to a better approach if you have one.  However,
> > libiberty.h must continue to work on a wide variety of host systems,
> > not just on GNU/Linux.
> 
> Ok, but...
>   ...why does libiberty.h duplicate declarations from other headers?

Because libiberty.h is designed to work correctly on a broad range of
different hosts.  Some hosts do not provide declarations for functions
like basename.  Some hosts do provide declarations for them.
libiberty.h must work correctly on all of them.

>   ...why are the declarations and macros not identical?

I'm not sure what you are referring to here.  The macros are defined
by the configure script, and they indicate whether the current host
defines the function.  They are not themselves declarations.

>   ...why doesn't e.g. string.h define HAVE_DECL_BASENAME?

Why should it?  HAVE_DECL_BASENAME is defined by the binutils
configure script.  string.h is not part of the binutils.

> Couldn't libiberty.h and the other header (such as string.h and stdio.h) be 
> consolidated, made compatible to each other? At least they are both in the 
> same project (binutils).

string.h and stdio.h are not part of the binutils project.  On
GNU/Linux, they are part of the glibc project.  On hosts other than
GNU/Linux, string.h and stdio.h are header files supplied by the
system.

> If demangle.h would not include libibety.h, I would not have this problem. 
> What's the purpose of libiberty and why does it duplicate declarations?

The purpose of libiberty is to provide a range of functions which are
not available on all hosts.

> Now I do:
>   #define HAVE_DECL_BASENAME 1
>   #define HAVE_DECL_ASPRINTF 1
>   #define HAVE_DECL_VASPRINTF 1
>   #define typename anotherNameThatsNotAKeyword
> before the include of demangle.h and the corresponding undefs after. But I 
> regard this as a dirty hack, that I would like to eliminate later.

The typename issue is clearly a bug, and as Nick noted it has already
been fixed.  The other issues are what we are talking about.

Before replying, I encourage you to read more about portability across
Unix hosts and about autoconf.  For example, I have written an
introduction here:
    http://www.airs.com/ian/configure/
The details are out of date, but the concepts are still correct.

Ian