Loading existing applications that linked against this into a
debugger should continue to work, so it shouldn't be obsoleted, but
the file is no longer installed.
Obsolete lines here will lead postinstall to delete the shlib, which
will break any existing applications linked against it. Deleting the
lines has no effect on postinstall.
(We should maybe have a different way to mark them instead, as
suggested in PR 57581, but we don't, so this is what we do for now.)
However, keep the obsolete line for libXxf86misc.so, since the .so
symlink itself is only used when linking new applications.
The Clang preprocessor does not mark sections from system headers.
Lint's strict bool mode relies on these markers to allow the functions
from <ctype.h> to be used as 'bool', even though their declared return
type is 'int'. Without these markers, lint complains that the "right
operand of '&&' must be bool, not 'int'". Until this is fixed in lint,
disable strict bool mode.
Noted by kre.
This doesn't break a passing test or fix a failed test, at least on
x86 -- our printf produces `0x1.533p+3' for the double case and
`0xa.99ap+0' for the long double case. But of the hexadecimal number
literals that that start with 0x5 having three hexadigits to the
right of the fractional point, 0x5.4cdp+1 closest to the IEEE 754
binary64, VAX D, x86 extended precision, and IEEE 754 binary128
floating-point numbers closest to 10.6.
The reason is that the number 10.6 (or the nearest floating-point
number in any format with enough precision) is:
101.0100 1100 1100|1100... * 2^1 = 0x5.4cc|c...p+1
If we round at the vertical bar to the _nearest_ output with three
hexadigits of precision, the result is:
101.0100 1100 1101 * 2^1 = 0x5.4cdp+1
compat/sparc64/sparc/bsd.sparc.mk doesn't define LIBC_MACHINE_CPU,
only LIBC_MACHINE_ARCH, so when the compat build gets to this
conditional, LIBC_MACHINE_CPU is just MACHINE_CPU, i.e., sparc64.
Since there's no `sparc64el' or `sparc64hf-el' that we need to
canonicalize by MACHINE_ARCH -> MACHINE_CPU, just use
LIBC_MACHINE_ARCH here.
These are trivial subroutines, not symbol aliases, for separate
reasons:
- frexpf has a different ABI from frexp (float vs double argument)
- frexp is defined in libc, not libm, so although long double is the
same as double, frexpl can't be an alias in libm of a symbol
defined in libc
LDBL_MAX is always defined, so this branch is dead. (If LDBL_MAX is
not defined, that's a bug in the architecture's float.h, not a reason
to skip a test.)
This reverts:
hdtoa.c 1.12 (PR/56247: Greg A. Woods: printf("%La", LDBL_MIN) dumps core)
hdtoa.c 1.11 (fix tyop)
hdtoa.c 1.10 (Via enh at google dot com in tech-userlevel. Fix handling of
EXT_FRAC{H,L}BITS (although we don't need to since we don't have them).)
The underlying motivation for this change was that when ld128 is
decomposed into 4x32 words, this hldtoa logic is broken.
But we don't decompose ld128 into 4x32 words; we decompose it into
6x64 words.
And the change, which was supposed to be a noop in our case of 2x64
words (or similar for x87 80-bit floating-point), broke it to the
point of causing buffer overruns (PR 56247) which when worked around
led to just incorrect output output (PR 56937).
If we want to make the #ifdefs for 4x32 words work, that's fine, but
we absolutely must have automatic test cases to detect this kind of
regression because %La formatting is extremely important for
diagnosing details of floating-point data since it doesn't involve
rounding in binary formats. For now I've added some trivial tests;
there is a more extensive test suite inside gdtoa that we need to
wire up before anyone tries any other shenanigans in this code.
PR lib/56937: printf(3) long double %a formatting is broken
1. Instead of calling out VAX by name, use #ifdef NAN and
isinf(INFINITY). (VAX defines INFINITY even though it's not an
infinity, not sure if there's a better compile-time test.)
2. Verify ilogbl works on long double on all architectures, not just
those with __HAVE_LONG_DOUBLE which means long double is _larger_
than double.
On this architecture vmt(4) used to search for a node "/hypervisor" in the
FDT and probed the VMware hypervisor call only when the node was
found. However, things appear to have changed and VMware no longer provides
the FDT node.
Since vmt(4) doesn't actually need to read anything from FDT, and the
hypervisor call logically resides in virtual CPUs themselves, it would be
better to attach it directly to cpu, just like how it's probed on x86.
slot, then set a new flag on that slot to indicate that the media
is non-removable. Make sdhc_card_detect always return true for a
slot if its non-removable media flag is set.
This change lets the kernel automatically configure the
permanently-installed MMC slot on the NXP LX2160-based HoneyComb
LX2 board.
32-bit has binary64 long double, same as double; 64-bit has binary128
long double, which is implemented with a few more symbols in libm
(which should maybe be hidden internal symbols, but let's get this
diagnostic measure in the build working before we think about
possibly deleting private symbols).
Otherwise, we get the wrong list of symbols for compat library
builds, where MACHINE_ARCH/CPU is different from
LIBC_MACHINE_ARCH/CPU, e.g. building compat 32-bit sparc libm on
sparc64.
XXX This is kinda kludgey -- `libc' seems wrong here.
This one was adapted from the screw case shown in
https://mail-index.netbsd.org/tech-userlevel/2020/04/11/msg012329.html
which wasn't broken in our libc, but which nevertheless prompted us
to commit a wrong and apparently untested patch that has rendered
printf %La broken for the last four years, which is a little
embarrassing. (The part of that patch that led to a buffer overrun
has been worked around, so now the output is just incorrect.)
PR lib/56937: printf(3) long double %a formatting is broken
riastradh