Re: Does Cygwin have str2sig/sig2str?

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2021-05-20 14:23, Joel Sherrill wrote:
> On Thu, May 20, 2021, 2:54 PM Corinna Vinschen wrote:
>> On May 20 09:58, Joel Sherrill wrote:
>>> The next POSIX version is wrapping up and unless something
>>> changes will be adding str2sig and sig2str. Does Cygwin have
>>> those?
>>> I'm asking to see if we adapt the Cygwin version for general use
>>> or have to write it from scratch.
>>> The glibc and Illumos implementations are what you would expect.
>>> They just use an array of { signal, string_name} and a lookup
>>> search.  Something similar would be OK for newlib.

>> I don't see glibc defining the above symbols in the master branch.

> Hmm ... Maybe google found someone's branch.

>> Cygwin exports two functions with equivalent functionality:
>>    char *strsignal (int signo);
>>    int strtosigno (const char *name);
>> see the file winsup/cygwin/strsig.cc.

> I think those are the bsd equivalents.

Functions strsignal, psignal, and psiginfo are related current POSIX 
interfaces: there are POSIX man pages for all three, and newlib man 
pages for strsignal, psignal, but none for psiginfo, and no Cygwin man 
pages for psiginfo or strtosigno, although the latter is declared in 
string.h with strsignal, and psiginfo is declared in cygwin/signal.h; 
Cygwin also exports sys_siglist, which is no longer exported by glibc.

> Would it be ok to generalize that and provide the new POSIX as well
> as the BSD interfaces?
See the POSIX proposal notes from kre for BSD interfaces which are 
different: signalname, signalnumber, signalnext

	https://www.austingroupbugs.net/view.php?id=1138

also notes on avoiding manifest constants and using sysconf interfaces, 
which may or may not affect the final specification.

It also notes glibc added sigabbrev_np; glibc also added sigdescr_np, 
(and spurious mentions of sigdabbrev_np, which appears to be a thinko) 
and stopped exporting sys_siglist.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]