After research, We think getnameinfo() is thread-safe. But, there
is not marking of getnameinfo() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think getaddrinfo(), freeaddrinfo() and
gai_strerror() 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>
After research, We think dl_iterate_phdr() is thread-safe. But, there
is not marking of dl_iterate_phdr() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think passwd2des(), xencrypt() and xdecrypt() 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>
After research, We think putgrent() is thread-safe. But, there
is not marking of putgrent() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think pthread_tryjoin_np() and
pthread_timedjoin_np() 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>
After research, We think pthread_getattr_np() is thread-safe. But,
there is not marking of pthread_getattr_np() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think pthread_cleanup_push() and
pthread_cleanup_pop() 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>
After research, We think pthread_attr_setaffinity_np() and
pthread_attr_getaffinity_np() 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>
After research, We think key_decryptsession(), key_setsecret(),
key_encryptsession(), key_gendes() and key_secretkey_is_set() 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>
After research, We think getpw() is thread-safe. But, there
is not marking of getpw() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think getnetent_r(), getnetbyname_r() and
getnetbyaddr_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>
In the "RETURN VALUE" section the word item is in italics
as if it were one of the function parameters. But the word
"item" occurs here for the first time, earlier the text
uses "element". [Patch improves this.]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I think the example is more accurate when we use the exact
locale names and also the Euro sign where appropriate.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Glibc 2.17 adds a function to read the frequency at which the Time
Base Register of Power processors is updated.
Signed-off-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think pthread_setname_np() and pthread_getname_np()
are thread-safe. But, there are not markings of pthread_setname_np()
and pthread_getname_np() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think pthread_join() is thread-safe. But, there
is not marking of pthread_join() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think pthread_detach() is thread-safe. But, there
is not marking of pthread_detach() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think pthread_create() is thread-safe. But, there
is not marking of pthread_create() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think pthread_cancel() is thread-safe. But, there
is not marking of pthread_cancel() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think pthread_attr_init() and pthread_attr_destroy()
are thread-safe. But, there are not markings of pthread_attr_init()
and pthread_attr_destroy() 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.
The marking of functions in glibc is:
- __fpurge: MT-Safe race:stream
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- sem_open: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think psiginfo() is thread-safe. But, there
is not marking of psiginfo() in glibc document.
psignal() matches glibc marking.
- psignal: MT-Safe locale
- psiginfo: MT-Safe locale
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think mq_notify() is thread-safe. But, there
is not marking of mq_notify() in glibc document.
- mq_notify: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think malloc_stats() is thread-safe. But, there
is not marking of malloc_stats() in glibc document.
- malloc_stats: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think malloc_info() is thread-safe. But, there
is not marking of malloc_info() in glibc document.
- malloc_info: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think getifaddrs() and freeifaddrs() are not
thread-safe. But, there is not markings of getifaddrs() and
freeifaddrs() in glibc document.
- getifaddrs: MT-Safe
- freeifaddrs: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Glibc 2.16 was released with a new function for the Power
architecture that can read its Time Base Register.
Signed-off-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The "ABI" doesn't really convey anything significant in
the title. These subsections are about describing differences
between the kernel and (g)libc interfaces.
Reported-by: Andries E. Brouwer <Andries.Brouwer@cwi.nl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
'cflags' is a bit mask of *zero* (not one) or more flags.
Reported-by: Laurence Gonsalves <laurence@xenomachina.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Remove erroneous second initialization of msg.msg_controllen
in the example code for SCM_RIGHTS.
See https://bugzilla.kernel.org/show_bug.cgi?id=15952
Reported-by: Christopher Head <chead@chead.ca>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
These functions don't exist in glibc, aren't specified
in C99 or C11 (those standards merely reserve the names
for future use), cause package conflicts for libcerf
(http://apps.jcns.fz-juelich.de/doku/sc/libcerf),
which does provide implementations and man-pages for
these functions, and cause confusion for readers
who (not looking too closely at the page) wonder
where the glibc implementation is. Best to simply
remove this page and its links from man-pages.
Reported-by: Joachim Wuttke <j.wuttke@fz-juelich.de>
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764310
and https://bugzilla.kernel.org/show_bug.cgi?id=80541
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This piece of text in the man page is ancient (from
man-pages-1.20, circa 1998), and odd in the sense that it
describes a bug in POSIX that was (long ago) subsequently
fixed. As the standards committee noted, POSIX here seemed
to deviate from existing practice. The simplest fix is
to just remove this BUGS section.
See https://bugzilla.kernel.org/show_bug.cgi?id=90261
Reported-by: Guy Harris <guy@alum.mit.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
>> +.BR resolv.conf(5),
>> +a local name server
>> .BR named (8),
>> a broken out line from \fI/etc/hosts\fP, and the Network
>> Information Service (NIS or YP), depending upon the contents of the
>> \fIorder\fP line in
>> .IR /etc/host.conf .
>
> Your patch didn't change the last few lines, but you may be able to
> help... Is the reference to "order" and /etc/host.conf on this page not
> obsolete by now. Looking at host.conf(5), one sees,
No, order *is* obsolete.
> Historical
> The nsswitch.conf(5) file is the modern way of controlling the
> order of host lookups.
>
> In glibc 2.4 and earlier, the following keyword is recognized:
>
> order This keyword specifies how host lookups are to be per‐
> formed. It should be followed by one or more lookup
> methods, separated by commas. Valid methods are bind,
> hosts, and nis.
>
> So, it looks like some fix is required here also. Right?
Yes. I didn't know how we wanted to talk about this particular topic.
The use of "order" is obsolete as of 2.5.
The following is a sketch of how I'd rewrite this to be more correct,
I'm out of time for today, but if you want to fix the formatting and
check it in that would be awesome.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The CPU_SET.3 man page uses the adjective "available" when
explaining what the argument to CPU_SET() means. This is
confusing, since "available" isn't well-defined. The kernel
has a set of adjectives (possible, present, online, and active)
that qualify cpus, but normally none of these are what the
cpu_set_t bit index means: it's just "which cpu", using the
kernel's internal numbering system, even if that cpu isn't
possible or present.
This change removes the word "available" and adds a sentence
warning that cpu sets may not be contiguous due to dynamic
cpu hotplug, etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The fscanf manpage contains this:
n Nothing is expected; instead, the number of characters
consumed thus far from the input is stored through the
next pointer, which must be a pointer to int. This is
not a conversion, although it can be suppressed with the
* assignment-suppression character. The C standard
says: "Execution of a %n directive does not increment
the assignment count returned at the completion of exe‐
cution" but the Corrigendum seems to contradict this.
Probably it is wise not to make any assumptions on the
effect of %n conversions on the return value.
posix manpages; all say that %n does *not* increase the counter.
%*n causes undefined behaviour according to c99+tc3. I wasn't
able to find proof that any Corrigendum says otherwise.
Therefore I think it's safe to say that you can indeed make the
assumption that %n does not affect the return value.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The gethostbyname(3) man page should first and foremost list that
the source of the data comes from the NSS plugins. I accept
that the man page is intentionally trying to be vague because
these things are not guaranteed anywhere, the truth is far
more mundane and "default" here IMO applies to a normal glibc
installation on Linux, and the fallback is always a localhost
nameserver.
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:
- sysconf: MT-Safe env
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
qsort() matches glibc marking.
>From research, We think qsort_r() is thread-safe. But, there
is not marking of qsort_r() in glibc document.
- qsort: MT-Safe
- qsort_r: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- putpwent: MT-Safe locale
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- on_exit: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- inet_ntop: MT-Safe locale
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- iconv_close: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- bsearch: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- atexit: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- strsignal: MT-Unsafe race:strsignal locale
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- sleep: MT-Unsafe sig:SIGCHLD/linux
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- setlogmask: MT-Unsafe race:LogMask
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- setlocale: MT-Unsafe const:locale env
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The markings match glibc markings.
markings of functions in glibc are:
- setjmp: MT-Safe
- sigsetjmp: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
mcheck() and mprobe() match glibc markings.
>From research, We think mcheck_pedantic() and mcheck_check_all() are not
thread-safe. But, there is not markings of mcheck_pedantic() and
mcheck_check_all() in glibc document.
- mcheck: MT-Unsafe race:mcheck const:malloc_hooks
- mcheck_pedantic: MT-Unsafe race:mcheck const:malloc_hooks
- mcheck_check_all: MT-Unsafe race:mcheck const:malloc_hooks
- mprobe: MT-Unsafe race:mcheck const:malloc_hooks
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The markings match glibc markings.
markings of functions in glibc are:
- longjmp: MT-Safe
- siglongjmp: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Zeng Linggang