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-10 19:01 UTC
====================================================================== 
Summary:                    Add strsignal(), sig2str() and str2sig() to the
standard.
====================================================================== 

---------------------------------------------------------------------- 
 (0004986) kre (reporter) - 2020-09-10 19:01
 https://www.austingroupbugs.net/view.php?id=1138#c4986 
---------------------------------------------------------------------- 
Re https://www.austingroupbugs.net/view.php?id=1138#c4984

It makes no real difference whether one or both of these are required to
be async-signal-safe - if one is, the other will be - they use the exact
same data mapping names to numbers, just one looks up the name, and
returns
the number, and the other looks up the number and returns the name.

It is getting the data that is the issue, the lookups and result returning
are not an issue.

While open/read/close are OK to use (as is stat() which might be needed),
malloc() is not, and until we see the file (its size, or perhaps its
contents)
we don't know how big the buffer might need to be.   If we have to
malloc()
we cannot be async-signal-safe.

Re https://www.austingroupbugs.net/view.php?id=1138#c4983 ... I am not
implementing Solaris, nor am I copying its
decisions.  We still allow (and actually generate some) static binaries
and they should work (and ideally keep on working into the future).  While
there are issues with running really old static binaries, with careful
attention by the system, it can be done.   But some data cannot help
needing
to be updated, that data cannot be built into the application, or any
library it uses, or it will certainly cause problems.   While I don't
really
care about these functions for NetBSD, as absolutely nothing would ever
use them, I do care that the standard isn't written in a way that
precludes
various different (reasonable) implementations.

The remote outside chance that some application might want to use
sig2str()
in a signal handler doesn't justify forcing a low quality implementation. 

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                          
2020-09-08 23:13 kre            Note Deleted: 0004979                        
2020-09-09 11:27 joerg          Note Added: 0004980                          
2020-09-10 10:55 geoffclare     Note Edited: 0004975                         
2020-09-10 10:59 geoffclare     Note Added: 0004981                          
2020-09-10 13:05 kre            Note Added: 0004982                          
2020-09-10 13:30 joerg          Note Added: 0004983                          
2020-09-10 14:31 geoffclare     Note Added: 0004984                          
2020-09-10 14:31 geoffclare     Note Edited: 0004984                         
2020-09-10 19:01 kre            Note Added: 0004986                          
======================================================================


  • [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
  • [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