diff options
| author | Michael Kerrisk <mtk.manpages@gmail.com> | 2017-10-30 11:48:53 +0100 |
|---|---|---|
| committer | Michael Kerrisk <mtk.manpages@gmail.com> | 2017-11-08 08:36:50 +0100 |
| commit | a86cae61894815fcc3f34afe8dc1e030fe9a72b5 (patch) | |
| tree | 62f54b29968e2ebf6c8b7ed1aa9426e5fe10a88d /man2 | |
| parent | 006ac5f09db05f5edd0cd87bb3a533ffc34f0c24 (diff) | |
| download | man-pages-a86cae61894815fcc3f34afe8dc1e030fe9a72b5.tar.gz | |
sigaltstack.2: Tighten the BUGS wording a little
From a conversation with Walter Harms:
> 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.
Reported-by: Walter Harms <wharms@bfs.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Diffstat (limited to 'man2')
| -rw-r--r-- | man2/sigaltstack.2 | 21 |
1 files changed, 13 insertions, 8 deletions
diff --git a/man2/sigaltstack.2 b/man2/sigaltstack.2 index 0214315b11..764ef96f39 100644 --- a/man2/sigaltstack.2 +++ b/man2/sigaltstack.2 @@ -323,6 +323,11 @@ if (sigaction(SIGSEGV, &sa, NULL) == -1) { .EE .in .SH BUGS +In Linux 2.2 and earlier, the only flag that could be specified +in +.I ss.sa_flags +was +.BR SS_DISABLE . In the lead up to the release of the Linux 2.4 kernel, .\" Linux 2.3.40 .\" After quite a bit of web and mail archive searching, @@ -331,13 +336,11 @@ In the lead up to the release of the Linux 2.4 kernel, .\" explained -- mtk a change was made to allow .BR sigaltstack () -to accept -.B SS_ONSTACK -in -.IR ss.ss_flags , -which results in behavior that is the same as when -.I ss_flags -is 0 (i.e., the inclusion of +to allow +.I ss.ss_flags==SS_ONSTACK +with the same meaning as +.IR "ss.ss_flags==0" +(i.e., the inclusion of .B SS_ONSTACK in .I ss.ss_flags @@ -346,7 +349,9 @@ On other implementations, and according to POSIX.1, .B SS_ONSTACK appears only as a reported flag in .IR old_ss.ss_flags . -On Linux, there is no need ever to specify this flag in +On Linux, there is no need ever to specify +.B SS_ONSTACK +in .IR ss.ss_flags , and indeed doing so should be avoided on portability grounds: various other systems |