Am 30.10.2017 11:50, schrieb Michael Kerrisk (man-pages): > 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. > > ? what about the other way around (general to special) .... the inclusion of SS_ONSTACK in ss.ss_flags is a no-op (setting ss.ss_flags=SS_ONSTACK will result in ss.ss_flags=0). The details about older release will be helpful for upgrading pruposes. So we can say: Since Linux 2.4 the inclusion .... does this help ? re, wh > > Thanks, > > Michael > -- 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
