Expand and clarify libc/kernel sigset_t differences. Also move
up the signature for rt_sigprocmask, similar to the way this is
done in clone.2.
Due to the history of sigprocmask, there are various notions of
what sigset_t refers to. This attempts to clarify the man page,
by giving the major instances different names:
- sigset_t is the glibc sigset_t (1024 bits)
- kernel_sigset_t is the kernel's sigset_t (64 bits)
- old_kernel_sigset_t is the pre-rt kernel's sigset_t (32 bits)
and explaining their difference in the NOTES. Even though the
sources do not refer to the various sigset_t's by these names, I
think it is important to be explicit, esp since sizeof(sigset_t)
would give an incorrect value for `sigsetsize` if written in a
source file that includes the libc headers.
Lastly, move the note on an incorrect `sigsetsize` causing
EINVAL up to the ERRORS section, so everything is in one place.
If CLONE_FILES is not set, the duplicated FDs nevertheless share
file offset and status flags via the open file description.
Reported-by: Elliott Hughes <enh@google.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Some "magic" symlinks created by the kernel (e.g., those under
/proc and /sys) report 'st_size' as zero. Modify the example
program to handle that possibility.
Reported-by: Ursache Vladimir <f35f22fan@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Avoid closing cfd if it is -1. Initialize buf1_avail, etc. to avoid
uninitialized memory access in the event that accept() fails. Remove
redundant setting of nfds. Fix tabs with spaces.
Do not try to read/write from/to file descriptors once an existing
connection is overwritten, the select() states are stale now.
Avoid writing zero bytes from the buffer and then closing the fd.
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
The man page for res_ninit() incorrectly says that it takes no
parameters, when in fact (and indeed according to the same page
further down) it has to take a res_state parameter.
As Rich Felker comments:
The stdio buffer associated with the fmemopen-obtained FILE,
and the output memory buffer into which it's writing, are
conceptually distinct entities, and there is no reason to
expect reasonable results if you modify the contents of a
setvbuf-associated buffer through other means while it's
associated with a FILE.
See http://stackoverflow.com/questions/38854163/using-rewind-on-a-file-opened-with-fmemopen
Reported-by: Rich Felker <dalias@libc.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The manpage claimed that the offset argument is ignored, and when
I interpreted that as "I don't need to set that register when
doing the syscall", I got failures. I was able to spot two reasons
for that:
What I probably ran into:
At least on x86-64, sys_mmap (in arch/x86/kernel/sys_x86_64.c)
always checks that the offset is page-aligned, even for
MAP_ANONYMOUS.
Another one, could probably trigger on 32-bit x86:
In do_mmap(), there is a check to ensure that pgoff together with
the allocation length won't cause an overflow, even for
MAP_ANONYMOUS.
Document that userspace should pass in zero, since that's
probably what everyone is doing already. (It would also be
possible to describe the constraints on the offset more
carefully, but zero works, and nobody should need to pass in
anything else.)
Signed-off-by: Jann Horn <jann@thejh.net>
There is a fallback to wait4(), but only if the kernel does
not provide a waitpid() system call.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk