[Octave-bug-tracker] [bug #39089] Incomplete list of OS signals in the builtin SIG function

[Dan Sebald]

Follow-up Comment #11, bug #39089 (project octave):

Ah yes, the C/C++ variation.  OK, I'll send an email and changeset to libgnu.

One question is how we should handle duplicates.  Right now Octave is
including duplicates in the list, e.g.,


ABRT 6
IOT  6
CLD  17
CHLD 17
POLL 29
IO   29


But sig2str() can't do that because the input is a number and the routine
doesn't return multiple definitions for that number, just picks the first
occurrence.


ABRT =  6
CHLD =  17
POLL =  29


is what results from scanning gnulibs sig2str().  Now, I sort of like what
Octave is currently doing, and it is quite easy for us to add in the few cases
where there are duplicates.  (There is a str2sig routine that allows us to
check if "CLD", "IOT", etc. are defined.)  Furthermore, we can do so in a way
that will avoid any problems in which GNULIB arranges things internally by,
say, checking for both "CLD" and "CHLD" (m.assign() applied twice on an
assignment should be no problem).  On the other hand, this is kind of bad
programming practice in the sense we are duplicating something that GNULIB's
sig2str() should be doing--they do keep track of both CLD and CHLD but sig2str
can only return one of them.

So, I'm wondering if we should make an argument to GNULIB to consider changing
sig2str() so that it somehow returns all the signal definitions for a given
number.  They would need some internal string buffer array or something and
return a pointer to it.  It just feels to me that the sig2str() routine isn't
complete the way it is.

Also, GNULIB is returning "EXIT" for the number zero in all cases:


    /* Older HP-UX versions.  */
#ifdef SIGDIL
    NUMNAME (DIL),
#endif

    /* Korn shell and Bash, of uncertain vintage.  */
    { 0, "EXIT" }


Should I exclude the number 0?  I think so.

Also, there is this SIGUNUSED in my signum.h file.  GNULIB doesn't check for a
SIGUNUSED.  Should we leave SIGUNUSED out of Octave's list?  Or keep it in to
reflect exactly what the user's system is defining?


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?39089>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/