Currently man3/gets.3 documents various safe I/O functions, along
with the toxic "gets" function.
At the risk of being melodramatic, this strikes me as akin to
storing rat poison in a food cabinet, in the same style of
packaging as the food, but with a post-it note on it saying
"see warnings below".
I think such "never use this" functions should be quarantined
into their own manpages, rather than listing them alongside
sane functions.
The attached patch does this for "gets", moving the documentation
of the good functions from man3/gets.3 into man3/fgetc.3,
updating the SO links in the relevant functions to point at the
latter.
It then rewrites man3/gets.3 to spell out that "gets" is toxic
and should never be used (with a link to CWE-242 for good
measure).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Linux AF_INET supports SOCK_SEQPACKET via SCTP.
Reported-by: Dongsheng Song <dongsheng.song@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The original list of registers was created by confusing strace
source code--this is for parsing legacy 32-bit code (which is
dead and no one cares). Update the list to reflect native ia64
syscall interface.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The manpage did not mention RB_POWER_OFF which is the glibc
symbolic name for LINUX_REBOOT_CMD_POWER_OFF.
$ cd /usr/include
$ cat x86_64-linux-gnu/sys/reboot.h | grep POWER_OFF
define RB_POWER_OFF 0x4321fedc
Signed-off-by: Elie De Brauwer <eliedebrauwer@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
POSIX.1-2001 mistakenly documented an ESRCH error, and
POSIX.1-2008 removes this error. Glibc does return
this error in cases where it can determine that a thread ID
is invalid, but equally, the use of an invalid thread ID
can cause a segmentation fault.
See http://thread.gmane.org/gmane.comp.lib.glibc.alpha/35598
Subject: Race and segmentation fault in pthread_kill() vs thread teardown
Newsgroups: gmane.comp.lib.glibc.alpha
Date: 2013-10-02 04:06:04 GMT
See http://udrepper.livejournal.com/16844.html
Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As reported by Janne Blomqvist:
currently the man page for mkostemp/mkostemps says:
The mkostemp() function is like mkstemp(), with the
difference that flags as for open(2) may be specified
in flags (e.g., O_APPEND, O_SYNC).
To be more precise, the implementation massages the flags argument
as follows:
(flags & ~O_ACCMODE) | O_RDWR | O_CREAT | O_EXCL
That is, there is no need to explicitly include O_RDWR | O_CREAT |
O_EXCL in flags, as it's added implicitly.
So I suggest that the manpage should instead state that
*additional* flags may be specified in the flags argument.
This issue is a potential portability problem. FreeBSD 10+ also
has mkostemp{s}, but generates an error if O_RDWR | O_CREAT |
O_EXCL is present instead of silently accepting it. While
annoying, this difference in behavior seems Ok by the proposed
addition of mkostemp to some future POSIX standard, see
http://austingroupbugs.net/view.php?id=411
The mkostemp() function shall be equivalent to the mkstemp()
function, except that the flag argument may contain
additional flags (from <fcntl.h>) to be used as if by open().
Behavior is unspecified if the flag argument contains more
than the following flags:
O_APPEND Set append mode.
O_CLOEXEC Set the FD_CLOEXEC file descriptor flag.
<SIO>O_DSYNC Write according to the synchronized I/O data
integrity completion.</SIO>
<SIO>O_RSYNC Synchronized read I/O operations.</SIO>
<XSI|SIO>O_SYNC Write according to synchronized I/O file
integrity completion.</XSI|SIO>
Reported-by: Janne Blomqvist <blomqvist.janne@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions sin(), sinf() and sinl() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk