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 following documents the E2BIG error return for
perf_event_open().
I actually ran into this error the hard way and it took me
half a day to figure out why my ->size value was changing.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
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>
When I asked to webmaster@kernel.org, Konstantin Ryabitsev
answered that the ".nl." is "an obsolete scheme and really
should be changed to just ftp.kernel.org".
Signed-off-by: Rodrigo Campos <rodrigo@sdfg.com.ar>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The existing text describes the timestamp fields as 'time_t'
and delegates discussion of nanosecond timestamps under NOTES.
Nanosecond timestamps have been around for a while now,
and are in POSIX.1-2008, so reverse the orientation of the
discussion, putting the nanosecond fields into DESCRIPTION
and detailing the historical situation under NOTES.
Reported-by: Yang Yang <yangyang.gnu@gmail.com>
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>
Peng Haitao