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>
This reflects glibc commit cad64f778aced84efdaa04ae64f8737b86f063ab
("ldconfig: Default to the new format for ld.so.cache").
Signed-off-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The terms POSIX.1-{2003,2004,2013,2016} were inventions of
my imagination, as confirmed by consulting Geoff Clare of
The Open Group. Remove these names.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Avoid implying that use of IFUNC is the only way to produce a
symbol with NULL value. Give more scenarios how a symbol may get
NULL value, but explain that in those scenarios dlsym() will fail
with Glibc's ld.so due to an implementation inconsistency.
Signed-off-by: Alexander Monakov <amonakov@ispras.ru>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
iproute2 allows you to specify the netns for either side of a veth
interface at creation time. Add an example of this to veth(4) so
it doesn't sound like you have to move the interfaces in a
separate step.
Verified with commands:
# ip netns add alpha
# ip netns add bravo
# ip link add foo netns alpha type veth peer bar netns bravo
# ip -n alpha link show
# ip -n bravo link show
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Adding description of new directories (/run, /usr/libexec,
/usr/share/color,/usr/share/ppd, /var/lib/color), stating
/usr/X11R6 as removed and updating URL to and version of FHS.
See https://bugzilla.kernel.org/show_bug.cgi?id=206693
Reported-by: Gary Perkins <glperkins@lit.edu>
Signed-off-by: Thomas Piekarski <t.piekarski@deloquencia.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As noted in email by Christian Brauner:
I forgot to mention that spawning directly into a target
cgroup is also more efficient than moving it after creation.
The specific reason is mentioned in the commit message
[ef2c41cf38a], the write lock of the semaphore need not be
taken in contrast to when it is moved afterwards. That
implementation details is not that interesting but it might
be interesting to know that it provides performance benefits
in general.
Reported-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk