Simon Josefsson wrote: > > We would need to have two modules 'sig2str-posix' and 'sig2str-gnu'. > > Not worth it, in my opinion. > > Replacing the sig2str function and making it return "EXIT" for 0 is > POSIX-compliant, isn't it? So no need for two modules, really. If we > follow that route, we could document that 'sig2str' go beyond the > minimum POSIX compatibility and chose to be compatible with FreeBSD.
So you would be proposing that we have a module 'sig2str-gnu' and no 'sig2str-posix'. This would mean that any program (like e.g. Python, guile, clisp, etc.) or library (like e.g. readline) that needs to print signal events would need to request 'sig2str-gnu' and thus, on FreeBSD, have code compiled and added to the executable, that is entirely equivalent to what FreeBSD already has in its libc. No, Gnulib does not work like this. When a system has a function in libc and it works perfectly fine, we don't override it. This would be bloat. > I wonder if there is ever going to be any reasonable use for 0 meaning > anything but "EXIT" though... did POSIX state any reason for this > unspecified behaviour? https://austingroupbugs.net/view.php?id=1138 has these: 1) Robert Elz writes: "I cannot even begin to imagine where a sig2str() function would be returning "EXIT" for "signal" 0 - 0 as a trap number relating to EXIT is a shell function, and has no place at all in the generic OS interface. The XBD page for signal.h says: The value 0 is reserved for use as the null signal (see kill( )). which has no relationship at all with anything relating to exit. But I suppose the Solaris function was defined for use in "trap -l" in sh, and so it was convenient to have 0 return "EXIT". That implementation quirk has no business being standardised here." 2) Geoff Clare writes: "As agreed in the Oct 8th teleconference, 0001138:0004975 has been updated to make the behaviour for a signum value of 0 unspecified." Bruno
