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>
Document the 'hidepid' and 'gid' mount options that were added in
Linux 3.3. See https://bugzilla.kernel.org/show_bug.cgi?id=90641
Based on text by Vasiliy Kulikov in
Documentation/filesystems/proc.txt.
Reported-by: Cameron Norman <camerontnorman@gmail.com>
Cowritten-by: Vasiliy Kulikov <segooon@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See https://bugzilla.kernel.org/show_bug.cgi?id=43300
Reported-by: David Wilcox <davidvsthegiant@gmail.com>
Reported-by: Filipe Brandenburger <filbranden@gmail.com>
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 existing text in this page:
MAP_SHARED Share this mapping. Updates to the mapping
are visible to other processes that map this
file, and are carried through to the underly‐
ing file. The file may not actually be
updated until msync(2) or munmap() is called.
implies that munmap() will sync the mapping to the underlying
file. POSIX doesn't require this, and some light reading of the
code and some light testing (fsync() after munmap() of a large
file) also indicates that Linux doesn't do this.
See also this mail thread:
Subject: munmap, msync: synchronization
Newsgroups: gmane.linux.man
Date: 2014-04-20 10:28:40 GMT
http://thread.gmane.org/gmane.linux.man/5548
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>
Rewrite the text somewhat, for easier comprehension.
No (intentional) changes to factual content
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk