Hi Walter,
On 10/30/2017 11:21 AM, walter harms wrote:
>
>
> Am 30.10.2017 11:04, schrieb Michael Kerrisk (man-pages):
>> [So, things fell on the floor, a while back.]
>>
>> On 05/25/2017 11:17 AM, Stas Sergeev wrote:
>>> 24.05.2017 14:09, Michael Kerrisk (man-pages) пишет:
>>>> One could do this I suppose, but I read POSIX differently from
>>>> you and, more importantly, SS_ONSTACK breaks portability on
>>>> numerous other systems and is a no-op on Linux. So, the Linux man
>>>> page really should warn against its use in the strongest terms.
>>> So how about instead of the strongest terms towards
>>> the code's author, just explain that SS_ONSTACK is a
>>> bit-value on some/many OSes, and as such, 0 is a
>>> valid value to enable sas on them, plus all the other
>>> values would give EINVAL?
>>> No strongest terms will help w/o an explanation,
>>> because people will keep looking for something that
>>> suits as a missing SS_ENABLE.
>>
>> Fair enough. I've removed the statement in the manual page
>> about "confusion". By now the page says:
>>
>> BUGS
>> In the lead up to the release of the Linux 2.4 kernel, a change
>> was made to allow sigaltstack() to accept SS_ONSTACK in
>> ss.ss_flags, which results in behavior that is the same as when
>> ss_flags is 0 (i.e., the inclusion of SS_ONSTACK in ss.ss_flags is
>> a no-op). On other implementations, and according to POSIX.1,
>
> i am confused, i understand that:
> ss.ss_sp = malloc(SIGSTKSZ);
>
> ss.ss_size = SIGSTKSZ;
> ss.ss_flags = 0;
> if (sigaltstack(&ss, NULL) == -1)
>
> is equivalent to:
> ss.ss_sp = malloc(SIGSTKSZ);
>
> ss.ss_size = SIGSTKSZ;
> ss.ss_flags = SS_ONSTACK ;
> if (sigaltstack(&ss, NULL) == -1)
>
> but also to
> ss.ss_sp = malloc(SIGSTKSZ);
>
> ss.ss_size = SIGSTKSZ;
> ss.ss_flags = SS_ONSTACK | SOMETHING_FLAG ;
> if (sigaltstack(&ss, NULL) == -1)
>
> so the use of SS_ONSTACK would result in ss.ss_flags = 0 no matter what.
> OR
> SS_ONSTACK is a no-op in Linux
I see what you mean. The point is back then that SS_ONSTACK was
the only flag that could (on Linux) be specified in ss.ss_flags,
so that "SS_ONSTACK | SOMETHING_FLAG" was a nonexistent case.
These days, it's possible to specify the new SS_AUTODISARM
flag in ss.ss_flags, which I think is why you are doubtful
about the new page text. How about this, as a tightened-up
version:
BUGS
In Linux 2.2 and earlier, the only flag that could be specified in
ss.sa_flags was SS_DISABLE. In the lead up to the release of the
Linux 2.4 kernel, a change was made to allow sigaltstack() to
allow ss.ss_flags==SS_ONSTACK with the same meaning as
ss.ss_flags==0 (i.e., the inclusion of SS_ONSTACK in ss.ss_flags
is a no-op). On other implementations, and according to POSIX.1,
SS_ONSTACK appears only as a reported flag in old_ss.ss_flags. On
Linux, there is no need ever to specify SS_ONSTACK in ss.ss_flags,
and indeed doing so should be avoided on portability grounds: var‐
ious other systems give an error if SS_ONSTACK is specified in
ss.ss_flags.
?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
