EXAMPLES appears to be the wider majority usage across various
projects' manual pages, and is also what is used in the POSIX
manual pages.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
man-pages doesn't have a REPORTING BUGS section in manual pages,
but many other projects do. Make some recommendations about
placement of that section.
man-pages doesn't use COPYRIGHT sections in manual pages, but
various projects do. Make some recommendations about placement
of the section.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Although man-pages doesn't use AUTHORS sections, many projects do
use an AUTHORS section in their manual pages, so mention it in
man-pages to suggest some guidance on the position at which
to place that section.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
There is one case of a cross-reference to a kernel documentation
filename that uses unescaped hyphens.
To avoid misrendering, escape these as \- similarly to other
instances.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add the PR_SPEC_DISABLE_NOEXEC mode added in Linux 5.1
for the PR_SPEC_STORE_BYPASS "misfeature" of
PR_SET_SPECULATION_CTRL and PR_GET_SPECULATION_CTRL.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Waiman Long <longman@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add the PR_SPEC_INDIRECT_BRANCH "misfeature" added in Linux 4.20
for PR_SET_SPECULATION_CTRL and PR_GET_SPECULATION_CTRL.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The fact that an FE_UNDERFLOW exception is not raised for
"Range error: result underflow" is intended behavior.
See https://www.sourceware.org/bugzilla/show_bug.cgi?id=6806.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The function make_message illustrates how to use vsnprintf to
determine the required amount of memory for a specific format and
its arguments.
If make_message is called with a format which will use exactly
INT_MAX characters (excluding '\0'), then the size++ calculation
will overflow the signed integer "size", which is an undefined
behaviour in C.
Since malloc and vsnprintf rightfully take a size_t argument, I
decided to use a size_t variable for size calculation. Therefore,
this patched code uses variables of the same data types as
expected by function arguments.
Proof of concept (tested on Linux/glibc amd64):
int main() { make_message("%647s%2147483000s", "", ""); }
If the code is compiled with address sanitizer (gcc
-fsanitize=address) you can see the following line, assuming that
a signed integer overflow simply leads to INT_MIN:
==3094==WARNING: AddressSanitizer failed to allocate 0xffffffff80000000 bytes
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Added in kernel commit b6fb293f2497a9841d94f6b57bd2bb2cd222da43
Text from comment in include/uapi/asm-generic/mman.h.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Added in kernel commit 16ba6f811dfe44bc14f7946a4b257b85476fc16e.
Text taken from comments in include/linux/mm.h.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This patch documents a flag added in the following kernel commit:
commit d2cd9ede6e193dd7d88b6d27399e96229a551b19
Author: Rik van Riel <riel@redhat.com>
Date: Wed Sep 6 16:25:15 2017 -0700
mm,fork: introduce MADV_WIPEONFORK
This was already documented in man2/madvise.2 in the commit:
commit c0c4f6c29c
Author: Rik van Riel <riel@redhat.com>
Date: Tue Sep 19 20:32:00 2017 +0200
madvise.2: Document MADV_WIPEONFORK and MADV_KEEPONFORK
Signed-off-by: Ian Rogers <irogers@google.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The gettid() wrapper was added glibc 2.30, and is declared by
<unistd.h> if _GNU_SOURCE is defined.
Reported-by: Joseph C. Sible <josephcsible@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Remove the text ("rare)" after a note from Vincent Lefèvre:
Subject: [Bug math/13932] dbl-64 pow unexpectedly slow for some inputs
Date: Sat, 23 May 2020 21:31:52 +0000
From: vincent-srcware at vinc17 dot net <sourceware-bugzilla@sourceware.org>
To: mtk.manpages@gmail.comhttps://sourceware.org/bugzilla/show_bug.cgi?id=13932
--- Comment #26 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
(In reply to Michael Kerrisk from comment #25)
> Fix documented for man-pages-5.07.
[...]
> -On 64-bits,
> +Before glibc 2.28,
> .\"
> .\" https://sourceware.org/bugzilla/show_bug.cgi?id=13932
> +on some architectures (e.g., x86-64)
> .BR pow ()
> may be more than 10,000 times slower for some (rare) inputs
> than for other nearby inputs.
[...]
The problematic values are uncommon, but not so rare, in the sense
that they are close to simple values, i.e. are likely to occur in
practice. An example given above: pow(0.999999999999999889, 1.5)
1 and 1.5 are very simple values, which are more likely to occur
in practice than some fixed random value. Then it suffices to have
a small rounding error on 1...
For instance, this is very different from hard-to-round cases of
exp, which are also very slow IMHO, but unless one writes a
specific program for them, no-one should notice the slowness
because such a case would typically occur only once among billions
(I don't remember the accuracy before the slowest path in this
library).
Reported-by: Vincent Lefèvre <vincent-srcware@vinc17.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk