This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


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

Re: libiberty strsignal changes cause windows compilation breakage


   Date: Thu, 01 Jun 2000 15:57:10 +1000
   From: Andrew Cagney <ac131313@cygnus.com>

   Chris Faylor wrote:
   > 
   > The strsignal file in libiberty was recently updated to include
   > "string.h".  This has an unpleasant side effect on cygwin in that the
   > declaration for strsignal in newlib's string.h is essentially this:

   POSIX doesn't appear to list strsignal().  Would you know its history? 
   First thing is to figure out what the definition should be according to
   a standard rather than someones passing whim.

It's marked as a GNU extension in the GNU C Library.  The copyright
date on the file that implements it suggests that it was created in
1991.  The first ChangeLog entry mentioning strsignal() is from April
1992.  If you're really interested you could ask Roland McGrath.

Both Solaris and FreeBSD have strsignal() too.  In all three cases
it's prototype is:

   extern char *strsignal (int);

So I'd suggest aligning libiberty with the rest of the world.

   Hmm, find | grep strsignal

	   convex-tdep.c:/* OBSOLETE */strsignal()
	   corelow.c: safe_strsignal()
	   sun386-nat.c:safe_strsignal()
	   umax-xdep.c:safe_strsignal()

   and utils.c defines save_strsignal().  Shouldn't corelow.c be calling
   target_signal_to_string()? I'll ignore sun386-nat.c and umax-xdep.c as
   we could probably slip in a ``OBSOLETE'' while no one was looking :-)

I'll be happy to look the other way :-)

Mark

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