As noted by Archie Cobbs:
I was trying to use srandom_() and initstate_r() and fell into
the exact same trap this this fellow did:
http://stackoverflow.com/questions/18569523/segfault-at-srandom-r,
resulting in a segfault.
The man page is really unclear here. It leads one to believe
(falsely) that invoking setrandom_r() is sufficient to initialize
a struct random_data, but this is not the case. In fact
srandom_r() is not like srandom() at all in this respect.
Reported-by: Archie Cobbs <archie.cobbs@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
When tzset is run the value of daylight is computed
by looking at all available rules for the application
of daylight savings. This includes reading the tzdata
files to determine if there is a transition or not for
the current timezone. It also includes parsing TZ env
to see if it specifies custom rules which are used in
precedence to any tzdata rules. Therefore daylight is
going to be set if there is a daylight saving rule past,
present, or future that indicates a transition. We clarify
that in the man page.
Lastly, the note about tz_dsttime is not correct and is
removed. The earlier paragraph about daylight makes it
clear that it doesn't mean "daylight saving rule applies
now", and the interaction with tz_dsttime is not correct
for glibc on Linux (as outlined in my gettimeofday.3 patch
sent here: http://marc.info/?l=linux-man&m=144977768703615&w=2).
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The following came up yesterday on the wget list.
The iconv.3 man page says
"... 2. The input byte sequence has been entirely converted,
i.e. *inbytesleft has gone down to 0."
and
"A different case is when inbuf is NULL or *inbuf is NULL,
but outbuf is not NULL and *outbuf is not NULL. In this case,
the iconv function attempts to set cd's conversion state to the
initial state and store a corresponding shift sequence at
*outbuf."
The POSIX page says
"For state-dependent encodings, the conversion descriptor cd is
placed into its initial shift state by a call for which inbuf
is a null pointer, or for which inbuf points to a null pointer.
When iconv() is called in this way, and if outbuf is not a null
pointer or a pointer to a null pointer, and outbytesleft points
to a positive value, iconv() shall place, into the output buffer,
the byte sequence to change the output buffer to its initial
shift state."
These texts are slightly misleading, in the sense that, in the
present implementation, iconv() may implement conversion
from an encoding that is not state-dependent in a way that
uses an artificial shift state to store lookahead bytes.
That means that after conversion, when *inbytesleft has gone
down to 0, it may be that contrary to what iconv.3 suggests not
all output has been stored, and a final flushing call is needed.
Maybe this violates POSIX.
A minimal warning is added by this patch.
--- man-pages-4.03/man3/iconv.3 2015-12-05 10:45:25.000000000 +0100
+++ ./iconv.3 2015-12-16 01:41:38.253049938 +0100
@@ -161,6 +161,11 @@
.SH CONFORMING TO
POSIX.1-2001, POSIX.1-2008.
.SH NOTES
+In each series of calls to
+.BR iconv (),
+the last should be one with \fIinbuf\fP or \fI*inbuf\fP equal to NULL,
+in order to flush out any partially converted input.
+
Although
.I inbuf
and
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Quoting Florian:
This does not work because libm.so can be a linker script:
handle = dlopen("libm.so", RTLD_LAZY);
The proper way to do this is to include <gnu/lib-names.h>
and use LIBM_SO.
See https://bugzilla.kernel.org/show_bug.cgi?id=108821
Reported-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As noted by Florian Weimer:
The manual daemon(3) manual page talks about the "calling
process's current working directory". I think this is
misleading because the function exits the calling process
before changing the current directory.
Reported-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
GNU C Library commit 1747fcda4902a3b46183d93fb16ed9b436b2608b
extends the priorities that can be set to the Program Priority
Register (PPR), with the functions: __ppc_set_ppr_very_low(3)
and __ppc_set_ppr_med_high(3).
Signed-off-by: Gabriel F. T. Gomes <gftg@linux.vnet.ibm.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As stated in the SYNOPSIS, since glibc 2.10 this function is also
declared by the relevant X/Open and POSIX macros.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
When the glibc implementation of posix_fallocate detects
that the underlying filesystem does not support fallocate()
it uses an emulation function to attempt to allocate the
space requested. The most common case is calling
posix_fallocatei() for a file that is on NFS where the
NFS server is not new enough to support the recent fallocate
extensions. This emulation has various serious caveats that
must be understood in order to use posix_fallocate robustly
on all filesystems. The change documents the caveats in the
glibc implementation.
Lastly, we expand the meaning of EINVAL to match POSIX
2013 (Issue 7). If the underlying filesystem doesn't support
posix_fallocate()i, the implementation can return EINVAL, but
glibc does not do this, it emulates the operation instead.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- mallinfo: MT-Unsafe init const:mallopt
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think
* getspnam(),
* getspent(),
* setspent(),
* endspent(),
* getspent_r(),
* fgetspent(),
* sgetspent(),
are not thread-safe. And
* putspent(),
* getspnam_r(),
* sgetspent_r(),
* lckpwdf(),
* ulckpwdf(),
* fgetspent_r(),
are thread-safe. But, there are not
markings of them in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
marking of function in glibc is:
- fgetgrent: MT-Unsafe race:fpwent
ps: We think race:fpwent in glibc maybe hard for users to understand,
and have sent a patch to the GNU libc community for changing it to
race:fgetpwent, however, something about the copyright impeded the progress.
Here we mark it "race:fgetpwent", so there is a little different.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
marking of function in glibc is:
- fgetgrent: MT-Unsafe race:fgrent
ps: We think race:fgrent in glibc maybe hard for users to understand,
and have sent a patch to the GNU libc community for changing it to
race:fgetgrent, however, something about the copyright impeded the progress.
Here we mark it "race:fgetgrent", so there is a little different.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In 2013 I brought up the discussion if M_ARENA_MAX and M_ARENA_TEST
were public parameters:
https://sourceware.org/ml/libc-alpha/2013-03/msg00376.html
Consensus among Siddhesh and myself was that they should be
public, and in fact they were already in the public header.
Therefore there may already be applications uses these constants
and expecting them to work. At best we could limit mallopt()'s
acceptance of the options, but that seems like a bad solution
that could lead to unexpected behavior for user applications.
A quick google search shows that there are packages relying on
these constants to tune the glibc malloc implementation.
Since glibc 2.10 the M_ARENA_TEST and M_ARENA_MAX features
have been part of the public interface with
--enable-experimental-malloc.
Since glibc 2.15 the experimental allocator has been on by default
and M_ARENA_TEST and M_ARENA_MAX have been more broadly used.
There are environment variables, without trailing underscore, that
can also be used to adjust these values at runtime i.e.
MALLOC_ARENA_MAX, and MALLOC_ARENA_TEST.
This change describes these two options in the mallopt(3) man page
along with their environment variables.
Tested with glibc master on x86_64 to verify it works as expected.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk