sigaltstack.2: Reword BUGS text to be a little clearer

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2017-10-30 11:03:41 +01:00
parent c854094fc0
commit 006ac5f09d
1 changed files with 18 additions and 8 deletions

View File

@ -323,28 +323,38 @@ if (sigaction(SIGSEGV, &sa, NULL) == -1) {
.EE
.in
.SH BUGS
In the lead up to the development of the Linux 2.4 kernel,
In the lead up to the release of the Linux 2.4 kernel,
.\" Linux 2.3.40
a change was made to allow this system call to accept
.\" After quite a bit of web and mail archive searching,
.\" I could not find the patch on any mailing list, and I
.\" could find no place where the rationale for this change
.\" 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.
is 0 (i.e., the inclusion of
.B SS_ONSTACK
in
.I ss.ss_flags
is a no-op).
On other implementations, and according to POSIX.1,
.B SS_ONSTACK
appears only as a reported flag in
.IR old_ss.ss_flags .
There is no need ever to specify this flag in
.IR ss.ss_flags
(and indeed, doing so decreases portability,
since some implementations
On Linux, there is no need ever to specify this flag in
.IR ss.ss_flags ,
and indeed doing so should be avoided on portability grounds:
various other systems
.\" See the source code of Illumos and FreeBSD, for example.
give an error if
.B SS_ONSTACK
is specified in
.IR ss.ss_flags ).
.IR ss.ss_flags .
.SH SEE ALSO
.BR execve (2),
.BR setrlimit (2),