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>