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

[Marc Waeckerlin]

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++.


> If C++ is something which 
> you care about, then I encourage you to get involved and to do it
> yourself during the release process.

If I had the time, I would so it, but beside of my own little C++ library, I 
have several other open projects. Some of them are on my homepage 
(marc.waeckerlin.org). Too many ideas, too few time... But it should be 
little effort for someone that already knows the environment.


> 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?
  ...why are the declarations and macros not identical?
  ...why doesn't e.g. string.h define HAVE_DECL_BASENAME?

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).

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?

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.


By the way: I wrote a small C++ library, one of it's modules is a StackTrace 
class, that collects a stack trace in the constructor, reads and evaluates 
the executable (using libelf) and can print a nicely formatted stack trace, 
including function name, file and line information of the stack. That's 
especially helpful, if a stacktrace is stored in exceptions, where they are 
thrown, and printed out in the unexpected handler. Next will be to evaluate 
shared libraries too, not only the executable, for more information. So I 
will have enough work to do on this library...
(if interested, see http://marc.waeckerlin.org/mrw-c++/index.html)


Thank's
Regards
Marc
-- 
Siemens Schweiz AG, ES12 / I-49
Marc Wäckerlin, System Ingenieur
Albisriederstrasse 245, CH-8047 Zürich
Telefon: ++41 58 558 32 29
mailto:address@hidden http://www.siemens.ch/es

++++ E-Mail Guidelines: email.waeckerlin.org ++++