Made .SH into .SS

This commit is contained in:
Michael Kerrisk 2007-05-16 02:45:55 +00:00
parent 6c36ac81bf
commit 8c87824d61
6 changed files with 48 additions and 47 deletions

View File

@ -155,7 +155,7 @@ for the accepted socket.
On error, \-1 is returned, and
.I errno
is set appropriately.
.SH "ERROR HANDLING"
.SS "Error Handling"
Linux
.BR accept ()
passes already-pending network errors on the new socket

View File

@ -438,7 +438,7 @@ on most other Unix systems doing this will result in an error.
.\" .BR execve(2)
.\" that could be exploited for denial of service by a suitably crafted
.\" ELF binary. There are no known problems with 2.0.34 or 2.2.15.
.SH HISTORICAL
.SS Historical
With Unix V6 the argument list of an
.BR exec ()
call was ended by 0,

View File

@ -79,41 +79,6 @@ The
function returns the previous value of the signal handler, or
.B SIG_ERR
on error.
.SH PORTABILITY
The original Unix
.BR signal ()
would reset the handler to SIG_DFL, and System V
(and the Linux kernel and libc4,5) does the same.
On the other hand, BSD does not reset the handler, but blocks
new instances of this signal from occurring during a call of the handler.
The glibc2 library follows the BSD behaviour.
If one on a libc5 system includes
.B "<bsd/signal.h>"
instead of
.B "<signal.h>"
then
.BR signal ()
is redefined as
.B __bsd_signal
and signal has the BSD semantics.
This is not recommended.
If one on a glibc2 system defines a feature test
macro such as
.B _XOPEN_SOURCE
or uses a separate
.B sysv_signal
function, one obtains classical behaviour.
This is not recommended.
Trying to change the semantics of this call using
defines and includes is not a good idea.
It is better to avoid
.BR signal ()
altogether, and use
.BR sigaction (2)
instead.
.SH NOTES
The effects of this call in a multi-threaded process are unspecified.
.PP
@ -159,6 +124,41 @@ and, when
.B _GNU_SOURCE
is defined, also
.IR sighandler_t .
.SS Portability
The original Unix
.BR signal ()
would reset the handler to SIG_DFL, and System V
(and the Linux kernel and libc4,5) does the same.
On the other hand, BSD does not reset the handler, but blocks
new instances of this signal from occurring during a call of the handler.
The glibc2 library follows the BSD behaviour.
If one on a libc5 system includes
.B "<bsd/signal.h>"
instead of
.B "<signal.h>"
then
.BR signal ()
is redefined as
.B __bsd_signal
and signal has the BSD semantics.
This is not recommended.
If one on a glibc2 system defines a feature test
macro such as
.B _XOPEN_SOURCE
or uses a separate
.B sysv_signal
function, one obtains classical behaviour.
This is not recommended.
Trying to change the semantics of this call using
defines and includes is not a good idea.
It is better to avoid
.BR signal ()
altogether, and use
.BR sigaction (2)
instead.
.SH "CONFORMING TO"
C89, C99, POSIX.1-2001.
.SH "SEE ALSO"

View File

@ -155,9 +155,10 @@ returns values of type
that are not measured in clock ticks
but in
.BR CLOCKS_PER_SEC .
.SH "CONFORMING TO"
SVr4, 4.3BSD, POSIX.1-2001.
.SH "HISTORICAL NOTES"
.PP
On older systems the number of clock ticks per second is given
by the variable HZ.
.SS "Historical"
SVr1-3 returns
.I long
and the struct members are of type
@ -168,9 +169,8 @@ V7 used
for the struct members, because it had no type
.I time_t
yet.
.PP
On older systems the number of clock ticks per second is given
by the variable HZ.
.SH "CONFORMING TO"
SVr4, 4.3BSD, POSIX.1-2001.
.SH "SEE ALSO"
.BR time (1),
.BR getrusage (2),

View File

@ -90,7 +90,7 @@ is deprecated and has only been provided for compatibility.
All new programs should use
.BR statfs (2)
instead.
.SH "HP-UX NOTES"
.SS "HP-UX Notes"
The HP-UX version of the
.I ustat
structure has an additional field,

View File

@ -32,7 +32,8 @@ vfork \- create a child process and block parent
.B #include <unistd.h>
.sp
.B pid_t vfork(void);
.SH "STANDARD DESCRIPTION"
.SH DESCRIPTION
.SS "Standard Description"
(From SUSv2 / POSIX draft.)
The
.BR vfork ()
@ -51,7 +52,7 @@ was called, or calls any other function before successfully calling
or one of the
.BR exec ()
family of functions.
.SH "LINUX DESCRIPTION"
.SS "Linux Description"
.BR vfork (),
just like
.BR fork (2),
@ -86,7 +87,7 @@ but may call
Signal handlers are inherited, but not shared.
Signals to the parent
arrive after the child releases the parent's memory.
.SH "HISTORIC DESCRIPTION"
.SS "Historic Description"
Under Linux,
.BR fork (2)
is implemented using copy-on-write pages, so the only penalty incurred by