A NOTE has been added to this issue. 
====================================================================== 
https://www.austingroupbugs.net/view.php?id=1138 
====================================================================== 
Reported By:                joerg
Assigned To:                
====================================================================== 
Project:                    1003.1(2016)/Issue7+TC2
Issue ID:                   1138
Category:                   System Interfaces
Type:                       Enhancement Request
Severity:                   Editorial
Priority:                   normal
Status:                     New
Name:                       Jörg Schilling 
Organization:                
User Reference:              
Section:                    System Interfaces 
Page Number:                new interface 
Line Number:                newinterface 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2017-04-27 12:02 UTC
Last Modified:              2020-09-08 23:12 UTC
====================================================================== 
Summary:                    Add strsignal(), sig2str() and str2sig() to the
standard.
====================================================================== 

---------------------------------------------------------------------- 
 (0004979) kre (reporter) - 2020-09-08 23:12
 https://www.austingroupbugs.net/view.php?id=1138#c4979 
---------------------------------------------------------------------- 
Re: https://www.austingroupbugs.net/view.php?id=1138#c4977

    str2sig() and sig2str() exist since 32 years

I expect that's true, but in all that time, they've hardly been used,
or they would have been in the standard from the beginning.   The design
of these functions (as with others of that vintage) also leads a lot to
be desired.

    while it seems that the netbsd functions apparently have been
    been created just at the time when
https://www.austingroupbugs.net/view.php?id=1138#c3688 was entered

true as well, the requested functions were designed in a time when there
were no real concerns about defensive programming, and everyone knew that
if a "big enough" buffer was needed, one would be provided.   gets() was
still a popular function back then.    When I saw this issue I set out to
see if there might not be a better interface design that would solve the
same problem, and after some discussions on the NetBSD mailing lists, the
result is what was implemented, and then was published here in
https://www.austingroupbugs.net/view.php?id=1138#c3688

I'm not seriously expecting anyone to add the netbsd functions to posix,
or not any time soon - they haven't been around long enough, and aren't
widely supported enough.

I have no idea how web search engines decide what to show, or how they
locate man pages - the netbsd functions man page (one page for all 3
functions) has been around, and is and has been available on the web
for several years now.  You can find them at
      https://man.netbsd.org/signalname.3
They used to also be available via man-k.org but that seems to be
unavailable now.

But this is I think the crux of this issue:

    And BTW: stg2str(0, ...) returns "EXIT" as expected by the shell.

Yes, that has been made clear.   And what that says is that these
functions
are really internal shell interfaces.   Like any other internal shell
implementation detail, they have no real reason to appear in the standard.
As defined, they're essentially useless to anything other than the shell,
and its (usually) built in commands (a couple of them) and a few other
commands that are clones of those.   They have no general purpose
applicability
at all.   The only difference between these functions, and some other
local
function in the shell is that they can vary from system to system (but
they're
not the only instance of that).

The right thing to do is simply reject this enhancement request, and not
add
these functions to the standard at all.

I understand how it is useful for a shell implementation to be able to
depend
upon functions like these existing for each system the shell is to be used
upon, but that is not, IMO, a good enough reason for them to appear here.


If anyone ever finds a general purpose use for being able to translate
between
signal names and their equivalent numbers (which can't be achieved by
simply
including <signal.h> and referring to the defined names) then perhaps a
new
interface will be designed - maybe something like the NetBSD ones, maybe
not,
and perhaps if that need becomes widespread enough, in some later version
of
the standard, a decade or two from now, something could be added.   But
whatever that looks like, the chances of it (them) having an interface
anything like sig2str() is close to zero.   But I'm not going to hold my
breath, there is little need for the functionality provided (outside the
shell and related commands) so I can't see anyone bothering. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2017-04-27 12:02 joerg          New Issue                                    
2017-04-27 12:02 joerg          Name                      => Jörg Schilling 
2017-04-27 12:02 joerg          Section                   => System Interfaces
2017-04-27 12:02 joerg          Page Number               => new interface   
2017-04-27 12:02 joerg          Line Number               => newinterface    
2017-04-27 12:11 joerg          Note Added: 0003678                          
2017-04-27 13:32 schwarze       Note Added: 0003679                          
2017-04-27 14:15 joerg          Note Added: 0003680                          
2017-04-27 15:47 kre            Note Added: 0003681                          
2017-04-27 16:30 jilles         Note Added: 0003682                          
2017-04-28 02:14 kre            Note Added: 0003683                          
2017-04-28 02:49 kre            Note Added: 0003684                          
2017-05-04 10:57 joerg          Note Added: 0003685                          
2017-05-04 12:29 kre            Note Added: 0003686                          
2017-05-10 02:00 kre            Note Added: 0003688                          
2017-05-10 02:00 kre            Note Deleted: 0003683                        
2017-05-10 02:00 kre            Note Deleted: 0003684                        
2017-05-10 02:31 kre            Note Edited: 0003688                         
2017-05-10 02:31 kre            Note Edited: 0003688                         
2018-10-11 15:48 Don Cragun     Note Added: 0004148                          
2019-01-16 13:36 ajosey         Note Added: 0004212                          
2020-09-08 09:30 geoffclare     Note Added: 0004975                          
2020-09-08 09:30 geoffclare     Note Edited: 0004975                         
2020-09-08 15:32 kre            Note Added: 0004976                          
2020-09-08 21:37 joerg          Note Added: 0004977                          
2020-09-08 22:49 kre            Note Added: 0004978                          
2020-09-08 23:12 kre            Note Added: 0004979                          
======================================================================


            • ... Robert Elz via austin-group-l at The Open Group
              • ... Mark Harris via austin-group-l at The Open Group
              • ... Geoff Clare via austin-group-l at The Open Group
              • ... Steffen Nurpmeso via austin-group-l at The Open Group
              • ... Robert Elz via austin-group-l at The Open Group
              • ... Geoff Clare via austin-group-l at The Open Group
      • Re:... Robert Elz via austin-group-l at The Open Group
        • ... Geoff Clare via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Garrett Wollman via austin-group-l at The Open Group
    • Re: [10... Robert Elz via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to