Glibc's bindresvport() takes no notice of sin->sin_port:
it always returns an arbitrary reserved port in the
anonymous range (512-1023). (Reported by Mats Wichmann.)
Also:
* Add EADDRINUSE and EACCES errors.
* Mention use of getsockname(2).
* Other minor rewrites and reorderings of the text.
* Explicitly note that glib's bindresvport() ignores
sin->sin_port.
* Change license There's now virtually no text remaining from
the 1.70 version of this page.
Reported-by: Mats Wichmann <mats.d.wichmann@intel.com>
Reviewed-by: Mats Wichmann <mats.d.wichmann@intel.com>
Reviewed-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Clean up the $LANGUAGE description, by removing bogus comments
from setlocale(3) and expanding the mention in locale(7).
Maybe you will decide that a more detailed description should be left
to the gettext(3) documentation, but I actually care about the invisible
part of the patch more since the comments have put me off the track
initially ($LANGUAGE has nothing to do with setlocale(3) and is
completely isolated to gettext, as obvious from the glibc sources).
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
dladdr() will act unexpectedly if called from non-pic code on a
compile-time-generated function pointer:
/* test_dladdr.c */
#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>
int
main(void)
{
void *func;
Dl_info info = {};
func = printf;
dladdr(func, &info);
printf("%s at %p resolved from %s\n", info.dli_sname,
func, info.dli_fname);
return 0;
}
$ cc test_dladdr.c -ldl
$ ./a.out
printf at 0x804838c resolved from ./a.out
$ cc -fPIC test_dladdr.c -ldl
$ ./a.out
_IO_printf at 0xb7f71c30 resolved from /lib/libc.so.6
In the long term, it might make sense to make dladdr() recognize
plt pointers and recurse, but I'm too afraid of Ulrich ;-)
(and he seems to be heavy proponent of pic code anyway, so
the chances for that to be accepted probably aren't high).
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This patch documents the order of the getaddrinfo(3) results
(RFC 3484), how should the application deal with that,
mentions the extremely common cause of having multiple
results per query (both IPv4 and IPv6 addresses available)
and mentions /etc/gai.conf.
(mtk: Minor tweaks, and note glibc version for /etc/gai.conf)
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
If an exit handler itself calls exit(3), the results are
undefined (see the POSIX.1-2001 specification of exit(3)).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
According to POSIX.1, using longjmp() to terminate execution of
a function registered using atexit() produces undefined results.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
According to POSIX.1, using longjmp() to terminate execution of
a function registered using atexit() produces undefined results.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It's a subtle point, but if a registered function itself
calls exit(3), then subsequent functions that were registered
with on_exit(3) will see the exit status given to the more
recent exit(3) call.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Many sockets man pages use the name 'sockfd' already.
For consistency, changes the others to do so as well.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The correct range for the return value is [-pi/2,pi/2].
(mtk's fix in the last change to the return value text was
a botch-up of a (correct) suggestion by Nicolas Francois.)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Loic Domaigne suggested some rewordings of the NOTES paragraph
that discusses the utility of asynchronous cancelability.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reviewed-by: Loic Domaigne <tech@domaigne.com>
Many pages still mention use of the obsolete sysctl(2) system
call, or used the term "sysctls"; rewrite these mentions to
instead be in terms of /proc interfaces.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The range is not [-pi/2, pi/2], but [-pi, pi].
(mtk: This error was reported by Nicolas Francois, and
should have been fixed in 3.11, but somewhere along the way,
the fix got lost.)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506299
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In EXAMPLE, note that PTHREAD_INHERIT_SCHED is the default for
the inherit scheduler attribute attribute.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reported-by: Loic Domaigne <tech@domaigne.com>
Loic Domaigne points out that if a system implements
SCHED_SPORADIC (which Linux does not), then other
fields are also specified in sched_param. The simple
solution is just to remove that phrase from the man
page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reported-by: Loic Domaigne <tech@domaigne.com>
The SYNOPSIS shows types for arguments and return values, but
these are really just suggestions: since the interfaces are
macros, the compiler won't catch all violations of
the "type rules". Warn the reader of this.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After review comments by Bert Wesarg:
* Explain that cpu_set_t is a bitset, but should be considered
opaque.
* A CPU set can be duplicated with memset().
* Size of a CPU set is rounded up to size of long.
* CPU_SETSIZE is in bits, but the setsize argument is in bytes.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reported-by: Bert Wesarg <bert.wesarg@googlemail.com>
Reviewed-by: Bert Wesarg <bert.wesarg@googlemail.com>
These macros return twice what they should because of thinko
in glibc 2.8 and earlier. The bug is fixed for glibc 2.9.
http://sourceware.org/bugzilla/show_bug.cgi?id=7029
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This page contains material moved out of sched_setscheduler(2).
It overwrites a previously existing link file with the same name.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Masanari notes that this is an FAQ for logger(1) and that
Solaris and FreeBSD document this point in syslog(3).
The glibc info page also hides this comment in its source:
Internally, there is also LOG_KERN, but LOG_KERN == 0,
which means if you try to use it here, just selects default.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
(After a suggestion by Vegard Nossum.)
Also made a few other small rewordings to in the initial
paragraph.
Reported-by: Vegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Many older pages use a handle_error() macro to do simple
error handling from system and library function calls.
Switch these pages to do similar.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Glibc switched to using a POSIX-specified error code for
this error case.
http://bugs.linuxbase.org/show_bug.cgi?id=2375
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Acked-by: Stew Benedict <stewb@linux-foundation.org>
Passing pointer arguments to makecontext() is possible,
but only on some architectures, and with no guarantees
of portability.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504699
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reported-by: Paul Evans <leonerd@leonerd.org.uk>
The page was a bit fuzzy in describing the return values for
various cases. In particular, it needed to be more explicit
in describing what happens for the "not found" case.
This is an analogous change to the previous change for
getpwnam.3, made after Andreas Henriksson's report.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504787
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The page was a bit fuzzy in describing the return values for
various cases. In particular, it needed to be more explicit
in describing what happens for the "not found" case.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504787
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reported-by: Andreas Henriksson <andreas@fatal.se>
The page was a bit fuzzy in describing the return values for
various cases. In particular, it needed to be more explicit
in describing what happens for the "not found" case.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504708
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reported-by: Andreas Henriksson <andreas@fatal.se>
According to POSIX.1-2001, the CLOCK_PROCESS_CPUTIME_ID and
CLOCK_THREAD_CPUTIME_ID clocks should be settable, but
currently they are not.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Rework the text that refers to sched_setscheduler(2) for
a description of the permissions required to change
the scheduling policy and priority.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk