Re: Make string.h strsignal prototype return const char *

[Jeff Johnston <jjohnstn at redhat dot com>]

Hans-Peter Nilsson wrote:
> Without this patch, I get an error building the "elinux"
> cris-axis-aout(!) libiberty multilib.  It seems that a target
> that defines __linux__ but doesn't use newlib/libc/sys/linux
> (which seems very i386-specific) and doesn't provide a strsignal

It "is" i386-specific at present and documented as such.  In theory one needs to 
add platform-specific code which has been separated into machine directories. 
Noone has attempted or offered to do this for any non-i386 platform as of yet.

> function by some other means, can't build newlib and target
> libiberty files currently, as in a combined newlib+binutils+gcc
> build.  It's arguable that such a target would be a bit out of
> line, but the build does break for the wrong reasons
> (cutnpasted):
>
> /home/hp/cvs_areas/combined/cris-aout-obj/gcc/xgcc -B/home/hp/cvs_areas/combined/cris-aout-obj/gcc/ -nostdinc -B/home/hp/cvs_area\
> s/combined/cris-aout-obj/cris-axis-aout/newlib/ -isystem /home/hp/cvs_areas/combined/cris-aout-obj/cris-axis-aout/newlib/targ-inc\
> lude -isystem /home/hp/cvs_areas/combined/combined/newlib/libc/include -B/tmp/cris-aout/cris-axis-aout/bin/ -B/tmp/cris-aout/cris\
> -axis-aout/lib/ -isystem /tmp/cris-aout/cris-axis-aout/include -isystem /tmp/cris-aout/cris-axis-aout/sys-include -L/home/hp/cvs_\
> areas/combined/cris-aout-obj/ld -c -DHAVE_CONFIG_H -O2 -g -O2  -melinux -mbest-lib-options -I. -I/home/hp/cvs_areas/combined/comb\
> ined/libiberty/../include  -W -Wall -Wtraditional -pedantic /home/hp/cvs_areas/combined/combined/libiberty/strsignal.c -o strsign\
> al.o
> /home/hp/cvs_areas/combined/combined/libiberty/strsignal.c:413: error: conflicting types for 'strsignal'
> /home/hp/cvs_areas/combined/combined/newlib/libc/include/string.h:79: error: previous declaration of 'strsignal' was here
> /home/hp/cvs_areas/combined/combined/libiberty/strsignal.c: In function 'psignal':
> /home/hp/cvs_areas/combined/combined/libiberty/strsignal.c:567: warning: comparison between signed and unsigned
> make[4]: *** [strsignal.o] Error 1
> make[4]: Leaving directory `/home/hp/cvs_areas/combined/cris-aout-obj/cris-axis-aout/elinux/libiberty'
>
> The compilation error is due to a mismatch between the libiberty
> and newlib prototypes, and it seems the libiberty prototype is
> the correct one.  

I'm not sure I agree with your conclusion that libiberty is the one that is 
correct.  In newlib, strsignal is a glibc extension (i.e. it is not POSIX, C99, 
ANSI, or SUSV3) and is taken directly from glibc.  The description of the 
routine from glibc online documentation is:

 -- Function: char * strsignal (int SIGNUM)
     This function returns a pointer to a statically-allocated string
     containing a message describing the signal SIGNUM.  You should not
     modify the contents of this string; and, since it can be rewritten
     on subsequent calls, you should save a copy of it if you need to
     reference it later.

     This function is a GNU extension, declared in the header file
     `string.h'.


The following is found in my system's /usr/include/libiberty.h

/* Return a signal message string for a signal number
   (e.g., strsignal (SIGHUP) returns something like "Hangup").  */
/* This is commented out as it can conflict with one in system headers.
   We still document its existence though.  */

/*extern const char *strsignal PARAMS ((int));*/

And in /usr/include/string.h

/* Return a string describing the meaning of the signal number in SIG.  */
extern char *strsignal (int __sig) __THROW;

I don't know the history behind why it is declared differently, but this should 
at least explain why newlib has chosen the declaration it has.

An alternative to your solution would be to move the strsignal declaration out 
of string.h and into a new libc/sys/linux/sys/string.h.  Have string.h #include 
<sys/string.h>.  In libc/include/sys/string.h have a placeholder comment.  With 
the exception of sys/config.h I'm not too keen on having linux-only stuff in 
shared header files, especially since libc/sys/linux overrides many headers 
already to avoid this mess.

If I put this together, would you be willing to try it out?

-- Jeff J.