Make it a little more evident that the caller should not
pass a previously allocated buffer to open_memstream().
Reported-by: Rasmus Villemoes <Rasmus.Villemoes@decode.is>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since glibc 2.22 getaddrinfo() etc. are only declared for
POSIX.1-2001 or later.
Reported-by: Andreas Schwab <schwab@suse.de>
Reported-by: Orion Poplawski <orion@cora.nwra.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The glibc implementation of posix_fallocate(), which calls
fallocate(), may be interrupted. The fallocate() emulation
also makes use of pread()/pwrite(), which may also be
interrupted.
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Include also some information from comments by Florian Weimer,
Paul Eggert, and Rich Felker.
Reported-by: Florian Weimer <fweimer@redhat.com>
Reported-by: Rich Felker <dalias@aerifal.cx>
Reported-by: Paul Eggert <eggert@cs.ucla.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The mixture of information across DESCRIPTION and NOTES did
not lend itself to easy reading...
While we're at it, add some missing details as well.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As suggested by Florian Weimer:
It may make sense to move this documentation to a separate
manual page, specific to readdir_r. This will keep the
readdir() documentation nice and crisp. Most programmers
will never have to consult all these details.
Reported-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As noted by Florian:
The kernel does not return valid values for _PC_NAME_MAX and
some file systems (such as CIFS, and CD-ROMs with Joliet
extensions once a kernel bug is fixed). The CIFS limit is
somewhere around 765, and not 255 as reported by the kernel.
If I recall correctly, Windows SMB servers can actually
exceed the 255 byte limit. The reason is that Windows NTFS
has a limit based on 16-bit UCS-2 characters, and after
UTF-8 conversion, the maximum length is more than 255 bytes.
Reported-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
_POSIX_SOURCE was a POSIX.1-1990 creation that was soon made
obsolete bu _POSIX_C_SOURCE. Retaining mention of it
in the feature test macro requirements section of the
SYNOPSIS doesn't contain important information, and may
mislead readers into actually trying to use this macro.
A few mentions of it a maintained in a some pages where
defining _POSIX_SOURCE inhibits some behavior.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Under the FTM requirements all of these pages document the
requirement for _ISOC99_SOURCE. And feature_test_macros(7) now
documents that "cc -std=c99" produces the same effect as defining
_ISOC99_SOURCE. So, all of these pages don't additionally need
to specify "or 'cc -std=c99'" under the FTM requirements
in the SYNOPSIS. Removing that redundant text also simplifies
the SYNOPSIS a little.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
_XOPEN_SOURCE_EXTENDED is obsolete (it existed in SUSv1, but not
subsequent standards). _XOPEN_SOURCE >= 500 produces the same
effects as (_XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED). Modifying
the SYNOPSIS of various ages that contain:
_XOPEN_SOURCE\ >=\ 500 ||
_XOPEN_SOURCE\ &&\ _XOPEN_SOURCE_EXTENDED
to just:
_XOPEN_SOURCE\ >=\ 500
This has the following benefits:
a) Simplifying the SYNOPSIS by removing ancient
historical information.
b) Preventing users from being misled into using
_XOPEN_SOURCE_EXTENDED in new source code.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Looking at <features.h> (or feature_test_macros(7)), one can
see that when _XOPEN_SOURCE is defined with the value 700
(or greater), then _POSIX_C_SOURCE is defined with the value
200809L (or greater). Therefore, terms in the man pages such as
_XOPEN_SOURCE\ >=\ 700 || _POSIX_C_SOURCE\ >=\ 200809L
can be simpified to:
_POSIX_C_SOURCE\ >=\ 200809L
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Looking at <features.h> (or feature_test_macros(7)), one can
see that when _XOPEN_SOURCE is defined with the value 600
(or greater), then _POSIX_C_SOURCE is defined with the value
200112L (or greater). Therefore, terms in the man pages such as
_XOPEN_SOURCE\ >=\ 600 || _POSIX_C_SOURCE\ >=\ 200112L
can be simplified to:
_POSIX_C_SOURCE\ >=\ 200112L
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>`
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Looking at <features.h> (or feature_test_macros(7)), one can
see that when _XOPEN_SOURCE is defined with the value 600
(or greater), then _POSIX_C_SOURCE is defined with the value
200112L (or greater). Therefore, terms in the man pages such as
_XOPEN_SOURCE\ >=\ 600 || _POSIX_C_SOURCE\ >=\ 200112L
can be simpified to:
_POSIX_C_SOURCE\ >=\ 200112L
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Update to use _DEFAULT_SOURCE, and also changes brought by
glibc commit 266865c0e7b79d4196e2cc393693463f03c90bd8.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The discussion of nonlocal gotos is much easier to read if
setjmp() and longjmp() are discussed in the same page. While
we're at it, rework almost the entire text and add several
more details.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
There the reader will see the just expanded discussion of
why nonlocal gotos can make code harder to maintain.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The warning that nonlocal gotos make a program hard to maintain
is also given in setjmp(3). No need to repeat it here.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As noted by Carlos, there's quite a bit of inconsistency across
pages. Use 'addr' and 'addrlen' consistently in variables and
function arguments.
Cowritten-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The list of conditions determining if iruserok() and ruserok()
functions automatically fail is incomplete. According to glibc
source code, the functions also fail if the .rhosts file
is hard linked anywhere.
[Information verified from iruserfopen() function in inet/rcmd.c]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>
After research, we think
* dlinfo()
is thread-safe. But, there are not markings of it in
glibc document.
[mtk: split out of a larger dlopen() patch]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think
* dlsym(),
* dlvsym()
are thread-safe. But, there are not markings of them in
glibc document.
[mtk: Split out patch for formerly single dlopen.3 page]
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, we think
* dlopen(),
* dlmopen(),
* dlclose()
are thread-safe. But, there are not markings of them in
glibc document.
[mtk: Split out patch for formerly single dlopen.3 page]
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, we think
* dlerror()
is thread-safe. But, there are not markings of it in
glibc document.
[mtk: Split out patch for formerly single dlopen.3 page]
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, we think
* dladdr(),
* dladdr1()
are thread-safe. But, there are not markings of them in
glibc document.
[mtk: Split out patches for formerly single dlopen.3 page]
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>