As reported by Casper Dik:
For some reason, many of the realpath() manual pages (BSD, Linux)
have words to the following effect:
Solaris may return a relative pathname when the path argument
is relative.
I have looked through the Solaris source files and have found no
such bug reported or fixed; the implementation from at least 1997
and beyond certainly doesn't have this problem and even the older
versions prepend getcwd() or chdir() to dirname and run getcwd()
in that directory.
Solaris does have a system call which may return relative
pathnames: resolvepath(). I believe that that function may have
confused earlier writers of realpath() manual pages and this was
later copied without verifying that fact.
realpath() existed in Solaris 2.0 as it came from SVr4.0 and even
at that time it returned the full, non-relative path.
Reported-by: Casper.Dik@oracle.com
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Change 'character(s)' to 'byte(s)' to make clear that these
functions operate on bytes, not wide / UTF8 characters.
(POSIX uses 'byte(s)' similarly, to make this point.)
Reported-by: Andries E. Brouwer <Andries.Brouwer@cwi.nl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Warn the reader that the pointer arguments can't be
interpreted as C style strings. Also, note possible
alignment requirements for the referenced bytes sequences,
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Overlooked to add this link in 3.38, when documentation of
qsort_r() was added to the qsort.3 page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>
David Prévot