Document fanotify_init(2) flag FAN_REPORT_NAME and the format of
the event info type FAN_EVENT_INFO_TYPE_DFID_NAME.
The fanotify_fid.c example is extended to also report the name of
the created file or subdirectory.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Matthew Bobrowski <mbobrowski@mbobrowski.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Document fanotify_init(2) flag FAN_REPORT_DIR_FID and event info
type FAN_EVENT_INFO_TYPE_DFID.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Matthew Bobrowski <mbobrowski@mbobrowski.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Amir Goldstein [Tue, 25 Aug 2020 11:40:54 +0000 (14:40 +0300)]
fanotify.7, fanotify_mark.2: Generalize documentation of FAN_REPORT_FID
With fanotify_init(2) flag FAN_REPORT_FID, the group identifies
filesystem objects by file handles in a single event info record
of type FAN_EVENT_INFO_TYPE_FID.
We intend to add support for new fanotify_init(2) flags for which
the group identifies filesystem objects by file handles and add
more event info record types.
To that end, start by changing the language of the man page to
refer to a "group that identifies filesystem objects by file
handles" instead of referring to the FAN_REPORT_FID flag and
document the extended event format structure in a more generic
manner that allows more than a single event info record and not
only a record of type FAN_EVENT_INFO_TYPE_FID.
Clarify that the object identified by the file handle refers to
the directory in directory entry modification events.
Remove a note about directory entry modification events and
monitoring a mount point that I found to be too confusing and out
of context.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Matthew Bobrowski <mbobrowski@mbobrowski.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Wed, 26 Aug 2020 18:54:13 +0000 (20:54 +0200)]
bpf-helpers.7: Really resync against latest kernel source
Jakub points out that my last resync may accidentally have been
against an old version of the kernel source, since the resync
resulted in many deleted lines. I suspect he may be right.
Let's resync against today's current kernel.
Reported-by: Jakub Wilk <jwilk@jwilk.net> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As a side effect, the parentheses of ``sizeof`` are not next to
the parentheses of the whole expression, and it is visually
easier to read.
Detailed rationale:
In C, successive multiplications are evaluated left to right (*),
and therefore here is what happens (assuming x86_64):
``(sizeof(x) * INT_MAX * 2)``:
1) sizeof(x) * INT_MAX (the type is the largest of both, which
is size_t (unsigned long; uint64_t)).
2) ANS * 2 (the type is again the largest: size_t)
``(INT_MAX * 2 * sizeof(x))``:
1) INT_MAX * 2 (the type is the largest of both, which is
int as both are int (int; int32_t), so the
result is already truncated as it doesn't fit
an int; at this point, the intermediate result
will be 2^32 - 2 (``INT_MAX - 1``) (if I did
the math right)).
2) ANS * 2 (the type is again the largest of both: size_t;
however, ANS was already incorrect, so the
result will be an incorrect size_t value)
Michael Kerrisk [Tue, 25 Aug 2020 11:49:02 +0000 (13:49 +0200)]
Makefile: Fix lintian.debian.org URL in comment
From the email conversation:
From: Jakub Wilk <jwilk@jwilk.net>
Subject: Re: [bug] Makefile: Broken link
* Alejandro Colomar <colomar.6.4.3@gmail.com>, 2020-08-25, 12:51:
>Line 32 on the Makefile has a broken link in a comment:
>
>https://lintian.debian.org/tags/manpage-has-errors-from-man.html
This Lintian tag was renamed recently:
https://salsa.debian.org/lintian/lintian/commit/844278682aafa1da
The current URL is:
https://lintian.debian.org/tags/groff-message.html
Reported-by: Alejandro Colomar <colomar.6.4.3@gmail.com> Reported-by: Jakub Wilk <jwilk@jwilk.net> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Jonathan Wakely [Fri, 7 Aug 2020 08:30:57 +0000 (09:30 +0100)]
strtod.3: Fix return value for underflow
In C89 strtod returns zero on underflow, but since C99 it can return
non-zero. This means the strtod.3 page contradicts all recent C and
POSIX standards. Both C and POSIX say "smallest normalized positive
number", but for consistency with HUGE_VAL, HUGE_VALF and HUGE_VALL
this patch uses the constants for those numbers.
Also slightly improve the presentation of return values for overflow.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Jonathan Wakely [Fri, 7 Aug 2020 08:30:06 +0000 (09:30 +0100)]
printf.3: Fix description of %a hexfloat output
The description of hexadecimal floating-point output is missing a
character describing the exponent. The guarantee of at least one digit
in the exponent is present in both C99 and POSIX.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Mike Frysinger [Sun, 26 Jul 2020 06:23:40 +0000 (02:23 -0400)]
drop "coding: UTF-8" header
This header is used inconsistently -- man pages are UTF-8 encoded
but not setting this marker. It's only respected by the man-db
package, and seems a bit anachronistic at this point when UTF-8
is the standard default nowadays.
Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A naked tilde ("~") renders poorly in PDF. Instead use "\(ti",
which renders better in a PDF, and produces the same glyph
when rendering on a terminal.
Reported-by: Geoff Clare <gwc@opengroup.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
queue.3: Comment out text for functions not in glibc (related: 6559169cac)
===========
DESCRIPTION
===========
I'm documenting ``CIRCLEQ_*`` macros in queue.3. While writing
this, I noticed that the documentation for some types of
queues/lists talked about swapping contents of two lists, but only
for some of them. I then found that those macros (``*_SWAP``)
don't exist in my system (Debian), but exist in BSD, and I also
found that a previous commit (6559169cac) commented out a lot of
the *_SWAP macros documentation, but not all, and the reason was
that they were not present on glibc.
I checked that I didn't have any of the *_SWAP macros on my glibc,
so I think this is probably that the commit simply forgot to
comment some of
them.
=======
TESTING
=======
I did ``sudo make`` and then visualized the man page with
``man 3 queue``, and the changes looked good.
I also noticed that the subsection ``Tail queue example`` contents
were wrong, as they contained calls to CIRCLEQ_* macros. I will
address that in a future patch, before I submit the patch
documenting CIRCLEQ_*.
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Mike Frysinger [Thu, 23 Jul 2020 21:53:33 +0000 (17:53 -0400)]
Various pages: Drop t comment header
Historically, a comment of the following form at the top of a
manual page was used to indicate too man(1) that the use of tbl(1)
was required in order to process tables:
'\" t
However, at least as far back as 2001 (according to Branden),
man-db's man(1) automatically uses tbl(1) as needed, rendering
this comment unnecessary. And indeed many existing pages in
man-pages that have tables don't have this comment at the top of
the file. So, drop the comment from those files where it is
present.
[mtk: completely rewrote commit message]
Reported-by: G. Branden Robinson <g.branden.robinson@gmail.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Bruno Haible [Mon, 20 Jul 2020 23:33:55 +0000 (01:33 +0200)]
posix_memalign.3: Clarify how to free the result of posix_memalign
The man page did not tell how a memory block obtained through
posix_memalign() can be freed. POSIX:2018 says it.
https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html
I verified using a test program that this is true for glibc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
projects / thirdparty / man-pages.git / log
