[Toybox] [PATCH] Improve signal name<->number conversions.

[enh]

thanks.

much lower priority for me (and i'm volunteering to fix it), but...
what should i do about the mac here? #if around the
linux-only/mac-only signals (SIGPOLL is linux-only, SIGEMT is
mac-only, for example).

also -- something i didn't know until just now -- it turns out that
the mac doesn't have real-time signals. i've attached a patch, but it
adds #ifs to lib.c which doesn't currently have them, so i don't know
if you'd prefer me to move those bits to portability.c? (i also didn't
know whether you'd prefer big "linux" vs "macOS" #ifs or per-constant
#ifs, but assumed the former given the complaints i've heard about GNU
code...)



On Mon, Jun 10, 2019 at 1:21 PM Rob Landley <rob at landley.net> wrote:
>
> On 6/10/19 10:23 AM, enh via Toybox wrote:
> > ping?
>
> Applied.
>
> > -*-
> >
> > i did think of a way we could maybe add a test for the real-time
> > signals: collect the value from `kill -l SIGRTMAX` and check that
> > `kill -l SIGRTMAX-1` is `$((sigrtmax - 1))`. (you might think that
> > SIGRTMIN/SIGRTMAX are constants, but SIGRTMIN varies based on how many
> > real-time signals the libc implementation has taken for itself, and on
> > MIPS at least SIGRTMAX is different. i think the BSDs differ from
> > Linux too.)
>
> They're compile time constants, I know they vary by architecture.
>
> > SIGHUP is probably (?) the same everywhere so we could have similar
> > for `kill -l HUP` and `kill -l 1`.
>
> I checked the kernel source with "grep -r SIGHUP arch/*/include include | grep
> define" and yes, they are. COuldn't tell you about macos.
>
> > given that `kill -l` was broken even for the easy cases before my
> > patch, i've at least attached the trivial HUP/1 test...
>
> Also applied.
>
> Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-mac-build.patch
Type: application/octet-stream
Size: 2292 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20190610/0fb18173/attachment-0002.obj>