The example code was a version that was not consistent with
the shell output shown on the page.
Reported-bY: Simon Paillard <spaillard@debian.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
fopen() permits, for example, both "w+b" and "wb+",
but only the latter is meaningful to fmemopen().
See http://sourceware.org/bugzilla/show_bug.cgi?id=12836
Reported-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
If 'mode' is append, but 'size' does not cover a null byte
in 'buf', then fmemopen() incorrectly sets the initial file
position to -1, rather than the next byte after the end of
the buffer.
See http://sourceware.org/bugzilla/show_bug.cgi?id=13151
Reported-by: Rich Felker <bugdal@aerifal.cx>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Append mode correctly sets the initial offset but does
not force subsequent writes to append at end of stream.
See http://sourceware.org/bugzilla/show_bug.cgi?id=13152
Reported-by: Rich Felker <bugdal@aerifal.cx>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
If size is zero, fmemopen() fails, This is surprising behavior,
and not specified in POSIX.1-2008.
See http://sourceware.org/bugzilla/show_bug.cgi?id=11216
Reported-by; Alex Shinn <alexshinn@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Note the use of open_memstream() to store XML output
directly into a buffer.
Reported-by: Jakub Jelinek <jakub@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The existing text slipped into talking about characters and
strings, which could mislead readers into thing that, for
example, searches for the byte '\0' are treated specially.
Therefore, rewrite in terms of "bytes" and "memory areas".
At the same time, make a few source file clean-ups.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The strchr(3) page does `not explain the behavior if the
character to search for is specified as a null character ('\0').
According to my copy of Harbison and Steele, since the terminator
is considered part of the string, a call such as:
strchr("hello", '\0')
will return the address of the terminating null in the specified
string.
strchr(3) is inconsistent with index(3) which states:
"The terminating null byte is considered to be
a part of the strings."
Adding such a note to strchr(3) is also important since it is not
unreasonable to assume that strchr() will return NULL in this
scenario. This leads to code like the following which is
guaranteed to fail should get_a_char() return '\0':
char string[] = "hello, world";
int c = get_a_char();
if (! strchr(string, c))
fprintf(stderr, "failed to find character in string\n");
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The value is not meant to be a maximum (as was specified in
SUSv3) but an initial guess at the required size
(as specified in SUSv4).
Reported-by: Ulrich Drepper <drepper@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The value is not meant to be a maximum (as was specified in
SUSv3) but an initial guess at the required size
(as specified in SUSv4).
Reported-by: Ulrich Drepper <drepper@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Document rcmd_af(), rresvport_af(), iruserok_af(), ruserok_af().
Also some restructuring and other clarifications.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
glibc stopped providing these interfaces with v2.2.
Nowadays, the user that finds these pages probably wants
the libdb API, so note this in the page.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337581
Reported-by: Brian M. Carlson <sandals@crustytoothpaste.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
David Prévot