The use of "symbols" in the existing description is confusing;
it's "bytes". Other fixes as well.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It is helpful to have a short description about what the different
functions in string.h do.
Signed-off-by: Moritz 'Morty' Strübe <morty@gmx.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Change "NULL pointer: to "NUL " or null pointer".
POSIX uses the term "null pointer", not "NULL pointer".
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
POSIX.1-2013 eases life when casting the dlsym() return value to a
function pointer
Reported-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>
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>
The functions toupper() and tolower() are thread safe with
exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions sincos(), sincosf() and sincosl() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The macros va_start(), va_arg(), va_end() and va_copy() are
thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The function wcsncasecmp() is thread safe with exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The function wcscasecmp() is thread safe with exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The function wcswidth() is thread safe with exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions wcstoimax() and wcstoumax() are thread safe with
exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
NOTES already described how glibc differs from POSIX.
Add a pointer to that text from the point in DESCRIPTION
where hints==NULL is discussed.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The function wcwidth() is thread safe with exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The function wctype() is thread safe with exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The function wctrans() is thread safe with exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions futimes() and lutimes() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions erfc(), erfcf() and erfcl() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions erf(), erff() and erfl() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions expm1(), expm1f() and expm1l() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions cos(), cosf() and cosl() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions asinh(), asinhf() and asinhl() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions copysign(), copysignf() and copysignl() are thread
safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions atoi(), atol() and atoll() are thread safe with
exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The function atof() is thread safe with exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions atan(), atanf() and atanl() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It's not true that the return value is suitably aligned for "any
variable"; for example, it's unsuitable for a variable like
float *x __attribute__ ((__vector_size__ (32)));
which requires 32-byte alignment. Types like this are defined in
<avxintrin.h>, and with 16-byte alignment in <emmintrin.h> and
<xmmintrin.h>, so the application programmer need not even know
that a vector_size attribute has been applied.
On an x86 architecture, a program that loads from or stores to a
pointer with this type derived from malloc can crash because GCC
generates an aligned load/store, like MOVDQA.
The C99 standard (TC3, as of N1256) does say the return value is
suitably aligned for "any type of object". The C11 standard (as
of N1570) revises this to any type with "fundamental alignment",
which means an alignment "supported by the implementation in all
contexts", which I suppose tautologically includes aligning
malloc/realloc return values.
The actual behavior of current glibc malloc is to align to the
greater of 2 * sizeof(size_t) and __alignof__ (long double),
which may be one bit greater than this commit promises.
Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions ecb_crypt(), cbc_crypt() and des_setparity() are
thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions creal(), crealf() and creall() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions cproj(), cprojf() and cprojl() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions cbrt(), cbrtf() and cbrtl() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions euidaccess() and eaccess() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions statvfs() and fstatvfs() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The printf(3) manpage says that a negative precision is taken to
be zero, whereas printf(3p) says that a negative precision is
taken as if the precision were omitted. glibc agrees with the
latter (POSIX) specification.
Test code:
printf("%f\n",42.0); // "42.000000"
printf("%.*f\n",0,42.0); // "42"
printf("%.*f\n",-1,42.0); // "42.000000"
This patch corrects the explanation to match what actually happens.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk