Charles-François Natali added the comment:
> Jan-Philip Gehrcke added the comment:
>
> Currently the docs say that signal.NSIG is "One more than the number of the
> highest signal number."
> ("https://docs.python.org/3.4/library/signal.html#signal.NSIG).
>
> In case of FreeBSD's _SIG_MAXSIG (128) the documentation is still wrong: the
> highest signal value MAX is 126 (see
> http://bugs.python.org/issue20584#msg210892). According to the docs, NSIG
> should then be 127.
Yeah, but it doesn't matter.
We shouldn't be exposing this constant in the first place, all that
matters is that we accept all valid signals, and we don't crash whe
passing an invalid once (ssee below).
> Steffen Daode Nurpmeso added the comment:
>
> #ifdef NSIG_MAX
> # undef NSIG
> # define NSIG NSIG_MAX
> #elif !defined NSIG
> # define NSIG ((sizeof(sigset_t) * 8) - 1)
> #endif
>
> should do the trick for Python on any POSIX system?
This assumes that sigset_t is implemented as a raw bitmap, which isn't
documented (is could be implemented by an arbitrary data structure).
On the other hand, it's really really likely, and should guarantee
that sigset & Co don't crash on too large values (or write to
arbitrary memory locations like fd_set when passed fd > FD_SETSIZE).
So I think we should go for the above patch (Steffen's), with a doc
update saying that "NSIG is a value larger than the largest signals".
If the OS headers don't provide it, it's not our business to try to
infer it.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20584>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
