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 ======================================================================