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>
Some of the sockets/network protocol pages included names of
the corresponding address family constants in the NAME line,
but this wasn't done consistently across all pages, and probably
it adds little value in those pages that did do this. So, remove
these constants from those pages that have them in the NAME
section.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Command names shown in NAME are normally just the basename,
not the full pathname of the command.
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>
Make it clear that 'timeout' interval will be rounded up to the
system clock granularity, and may overrun because of kernel
scheduling delays.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Make it clear that 'timeout' interval will be rounded up to the
system clock granularity, and may overrun because of kernel
scheduling delays.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Make it clear that 'timeout' is a minimum interval; the actual
interval will be rounded up to the system clock granularity,
and may overrun because of kernel scheduling delays.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Make it clear that 'timeout' is a minimum interval; the actual
interval will be rounded up to the system clock granularity,
and may overrun because of kernel scheduling delays.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Make it clear that 'timeout' is a minimum interval; the actual
interval will be rounded up to the system clock granularity,
and may overrun because of kernel scheduling delays.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Make it clear that 'timeout' is a minimum interval; the actual
interval will be rounded up to the system clock granularity,
and may overrun because of kernel scheduling delays.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>