- Update from version 4.2.0 to 4.2.1
- Update of rootfile
- Changelog
4.2.1
patches 1 to 12 from 4.2.0 have been built in to 4.2.1
Other bugs fixed in the 4.2 branch for the MPFR 4.2.1 release:
The + and space flags were ignored on NaN and Inf. While this was loosely
documented as such (without an explicit mention of these flags), the MPFR
manual also says that the flags have the same meaning as for the standard
printf function. So this was contradictory and regarded as a bug. Behaving
like the ISO C standard should give less surprise, and this is probably
what is expected (better for alignment purpose). See discussion (only for
NaN and the + flag at that time).
Corresponding changeset in the 4.2 branch: 3761bee3c.
Huge negative exponents can trigger integer overflows in mpfr_strtofr,
meaning undefined behavior. Two bugs have been identified: 1, 2. In
practice, the consequences may be incorrect results. But for the first bug,
it has been seen that a GCC optimization makes it invisible. There are
other issues with the code for huge exponents, but it is not clear whether
the problematic cases can occur in the context of mpfr_strtofr; such
potential bugs are not fixed yet.
Corresponding changesets in the 4.2 branch: 261d3852b (tests), 06e7b6bc1
(bug fixes).
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- Update from version 4.2.0p9 to 4.2.0p12
- Update of rootfile not required
- Changelog - additional patches from 10 to 12 over previous update
10 - GCC 12 emits a spurious "may be used uninitialized" warning on tests/tfpif.c
with -O1, and GCC 13 has the same issue also with -O2 (GCC bug 106155). This can
make some test scripts fail for the developers. The gcc-pr106155-workaround
patch provides a workaround for this bug in GCC.
Corresponding changeset in the 4.2 branch: c0031f1af.
11 - The mpfr_inp_str function does not handle the '\0' character correctly when it
is not a whitespace character (which is almost always the case in practice, or
really always the case). For instance, if the word is the sequence
{ '1', '\0', '2' }, the string "1" is passed to mpfr_set_str because '\0' is
regarded as a terminating null character, and one gets a valid number (1) while
'\0' in a word is necessarily invalid. This is fixed by the inp_str-nullchar
patch. The testcase in the repository cannot be provided in the patch because of
the null character in one of the files.
Corresponding changeset in the 4.2 branch: 6a68387b2.
12 - When '\0' is a whitespace character, i.e. when isspace(0) is true in the current
locale (as allowed by ISO C for non-"C" locales), the mpfr_strtofr function
regards a '\0' in the leading whitespace sequence as a whitespace. This is
incorrect, since from the definition of a string, the first '\0' is the
terminating null character (before the notion of whitespace is involved). In
such locales, this is a vulnerability, because characters after the terminating
null character are read to determine the result; however, such locales are rare
or nonexistent (Mutt's lib.h suggests that some systems have such locales, but
this was in 1998). This is fixed by the strtofr-nullchar patch.
Corresponding changeset in the 4.2 branch: 964fbaa31.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- Update version 4.2.0 from 4 bug patches to 9 bug patches
- Update of rootfile not required
- Bug fix changelog
5 The mpfr_reldiff function, which computes |b−c|/b, is buggy on special values,
e.g. on the following (b,c) values: (+Inf,+Inf) gives ±0 instead of NaN (like
NaN/Inf); (+0,+0) gives 1 instead of NaN (like 0/0); (+0,1) gives 1 instead of
Inf (like 1/0). Moreover, the sign of 0 for (+Inf,+Inf) or (−Inf,−Inf) is not
set, i.e. it is just the sign of the destination before the call; as a
consequence, results are not even consistent. These bugs are fixed by the
reldiff patch.
Corresponding changeset in the 4.2 branch: 81e4d4427.
6 The reuse tests are incomplete: the sign of a result zero is not checked, so
that it can miss bugs (one of the mpfr_reldiff bugs mentioned above, in
particular). The tests-reuse patch adds a check of the sign of zero and
contains other minor improvements.
Corresponding changeset in the 4.2 branch: e6d47b8f5.
7 The general code for the power function (mpfr_pow_general internal function) has
two bugs in particular cases: the first one is an incorrect computation of the
error bound when there has been an intermediate underflow or overflow (in such
a case, the computation is performed again with a rescaling, thus with an
additional error term, but there is a bug in the computation of this term), so
that the result may be rounded incorrectly (in particular, a spurious overflow
is possible); the second one occurs in a corner case (destination precision 1,
rounding to nearest, and where the rounded result assuming an unbounded
exponent range would be 2emin−2 and the exact result is larger than this value),
with the only consequence being a missing underflow exception (the underflow
flag is not set). These two bugs are fixed by the pow_general patch, which also
provides testcases.
Note: The second bug was introduced by commit 936df8ef6 in MPFR 4.1.0 (the code
simplification was incorrect, and there were no associated tests in the
testsuite).
Corresponding changesets in the 4.2 branch: 85bc7331c, 5fa407a6c, 9a16c173e.
8 The mpfr_compound_si function can take a huge amount of memory and time in some
cases (when the argument x is a large even integer and xn is represented exactly
in the target precision) and does not correctly detect overflows and underflows.
This is fixed by the compound patch, which also provides various tests.
Corresponding changesets in the 4.2 branch: 7635c4a35, 74d86a61f, 952fb0f5c,
a4894f68d, 7bb748775, f5cb40571, d87459969.
9 MPFR can crash when a formatted output function is called with %.2147483648Rg in
the format string. For instance: mpfr_snprintf (NULL, 0, "%.2147483648Rg\n", x);
This is fixed by the printf_large_prec_for_g patch, which also provides
testcases.
Corresponding changesets in the 4.2 branch: 686f82776, 769ad91a6.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- The base version has not changed but patches to fix 4 bugs have been released.
- Update to rootfile not required.
- Bug fix changelog
1 A test of the thousands separator in tsprintf.c is based on the output from
the GNU C Library up to 2.36, which is incorrect. The output has changed in
2.37 (partly fixed), so that tsprintf fails with glibc 2.37. The
tsprintf-thousands patch modifies the test to conform to POSIX and also
avoid the buggy case in 2.36 and below. However, this new test, which was
expected to succeed, triggers a serious bug in 2.37
(bug 30068 / CVE-2023-25139). We did not modify the test again since this
bug affects MPFR's mpfr_sprintf function, with a possible buffer overflow
in particular cases. This bug has been fixed in the 2.37 branch. In short,
this patch is useful (and needed) for a fixed glibc 2.37 and some other
libraries, depending on the current locales.
Corresponding changesets in the 4.2 branch: 4f03d40b5, 78ff7526d, e66bb7121.
2 The mpfr_ui_pow_ui function has infinite loop in case of overflow. This can
affect mpfr_log10, which uses this function (this is how this bug was
found). This bug is fixed by the ui_pow_ui-overflow patch (with testcases).
Corresponding changeset in the 4.2 branch: 0216f40ed.
3 The tfprintf and tprintf tests may fail in locales where decimal_point has
several bytes, such as ps_AF. This is fixed by the multibyte-decimal_point
patch, which makes the tests aware of the length of decimal_point.
Corresponding changeset in the 4.2 branch: 0383bea85.
4 In particular cases that are very hard to round, mpfr_rec_sqrt may yield a
stack overflow due to many small allocations in the stack, based on alloca().
This is due to the fact that the working precision is increased each step
(Ziv loop) by 32 or 64 bits only, until the approximate result can be
rounded (thus we have an arithmetic progression here, while a geometric
progression is used for the other functions), and that at each iteration,
the previous allocations in the stack cannot be freed. Individual
allocations in the stack are limited to 16384 bytes, so that the issue can
occur only when there are many iterations in working precisions that are
not too large, which is possible with an arithmetic progression. This bug
is fixed by the rec_sqrt-zivloop patch, which changes the Ziv loop to use
the standard MPFR_ZIV_* macros; the patch also provides a testcase obtained
by a function that constructs a hard-to-round case involving large enough
precisions (this function is commonly used in the MPFR testsuite, but not
with so large precisions). This bug was originally reported by Fredrik
Johansson.
Corresponding changeset in the 4.2 branch: 934dd8842.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
- Update from version 4.1.1 to 4.2.0
- Update of rootfile
- Changelog
Changes from versions 4.1.1 to version 4.2.0
Binary compatible with MPFR 4.0.* and 4.1.*, though some minor changes in
the behavior of the formatted output functions may be visible, regarded as
underspecified behavior or bug fixes (see below).
New functions mpfr_cosu, mpfr_sinu, mpfr_tanu, mpfr_acosu, mpfr_asinu,
mpfr_atanu and mpfr_atan2u.
New functions mpfr_cospi, mpfr_sinpi, mpfr_tanpi, mpfr_acospi, mpfr_asinpi,
mpfr_atanpi and mpfr_atan2pi.
New functions mpfr_log2p1, mpfr_log10p1, mpfr_exp2m1, mpfr_exp10m1 and
mpfr_compound_si.
New functions mpfr_fmod_ui, mpfr_powr, mpfr_pown, mpfr_pow_uj, mpfr_pow_sj
and mpfr_rootn_si (mpfr_pown is actually a macro defined as an alias for
mpfr_pow_sj).
Bug fixes.
In particular, for the formatted output functions (mpfr_printf, etc.),
the case where the precision consists only of a period has been fixed
to be like .0 as specified in the ISO C standard, and the manual has
been corrected and clarified.
The macros of the custom interface have also been fixed: they now behave
like functions (except a minor limitation for mpfr_custom_init_set).
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
- Update from version 4.1.0 with patch set 1 to 13 to 4.1.1 with aptch set 1 to 1
- Update of rootfile
- Changelog
Changes from version 4.1.0 to version 4.1.1:
- Bug fixes (see <https://www.mpfr.org/mpfr-4.1.0/#fixed> and/or the
ChangeLog file), in particular for macros implementing functions.
- Improved manual formatting.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
- Update from version 4.1.0 to 4.1.0 plus patches 1 to 13
- Version 4.1.0 was released on 10-07-2020. However patches have been progressively
issued to fix various bugs that have been identified.
- Currently 13 patches have been issued and mpfr provide a cumulative patches file to
use to patch the source file.
- Update of rootfile
- Patch changelog
1 With GCC (the only tested compiler with software _Decimal128), conversions of
double to _Decimal128 yield an increase of 2 to 3 MB for the generated library
code when the decimal encoding is BID (designed for software implementations),
even though the conversions done in MPFR are very simple. Details about this GCC
issue. The decimal128-conv patch avoids these conversions by directly using
_Decimal128 constants. Note that fixing the issue entirely would require to get
rid of all the decimal128 operations; in the mean time, decimal support (i.e.
mpfr_get_decimal128 and mpfr_set_decimal128 functions) could be disabled at
configure time.
Corresponding changeset in the 4.1 branch: 14094.
2 The random_deviate.c file contains non-portable code. This is fixed by the
random_deviate patch.
Corresponding changeset in the 4.1 branch: 14126.
3 In the mpfr_set_z_2exp function, a huge mpz_t value can yield an integer overflow.
This is fixed by the set_z_2exp-overflow patch (with testcases). Note that in
practice, an integer overflow may occur only with a 32-bit ABI. Moreover, with a
usual compilation, an integer overflow should here not yield any particular issue,
assuming that the processor does signed addition and multiplication modulo 2^32 (as
usual). However, UBsan would detect the overflow, and LTO might have unpredictable
effects.
Corresponding changesets in the 4.1 branch: 14147, 14151.
4 Some function prototypes are slightly inconsistent. This is valid C code, but
these inconsistencies are unintended and possibly confusing, and they trigger
diagnostics with the -Warray-parameter option of the future GCC 11 (included in
-Wall). This causes issues when testing MPFR. And since mpfr.h is concerned, this
might also affect user code. This is fixed by the prototypes patch.
Corresponding changeset in the 4.1 branch: 14411.
5 In uncommon cases, the mpfr_digamma function needs to use an intermediate
precision equal to the exponent of the input value, which may be huge. This is
inefficient, and the code can request more memory than available, yielding a crash.
The digamma-hugemem patch improves the implementation by making such a need much
rarer; it also provides testcases showing a crash on 64-bit machines (at least).
Corresponding changeset in the 4.1 branch: 14424.
6 The mpfr_digamma function may have an erratic behavior in some cases (an assertion
failure in debug mode). This is fixed by the digamma-interm-zero patch (with
testcase).
Corresponding changeset in the 4.1 branch: 14425.
7 The Bessel functions (mpfr_j0, mpfr_j1, mpfr_jn, mpfr_y0, mpfr_y1, mpfr_yn) may
have an erratic behavior in some cases (an assertion failure in debug mode). This
is fixed by the jn-interm-zero patch (with testcase).
Corresponding changeset in the 4.1 branch: 14426.
8 The mpfr_digamma function may have an erratic behavior in some cases (an assertion
failure in debug mode) when the reflection formula is used, i.e. when x < 1/2.
This is fixed by the digamma-interm-zero2 patch (with testcase).
Corresponding changeset in the 4.1 branch: 14435.
9 The Bessel functions (mpfr_j0, mpfr_j1, mpfr_jn, mpfr_y0, mpfr_y1, mpfr_yn) may
have an erratic behavior in some cases (an assertion failure in debug mode) when
the asymptotic expansion is needed. This is fixed by the jyn_asympt-interm-zero
patch (with testcase).
Corresponding changeset in the 4.1 branch: 14436.
10 Some functions are also implemented as macros, and such a macro should behave
exactly like the corresponding function (if the code is valid for the function
call). However, the following macros do not behave as if their argument were
implicitly converted to the type from the function prototype: mpfr_nan_p,
mpfr_inf_p, mpfr_zero_p, mpfr_regular_p, mpfr_get_prec, mpfr_get_exp,
mpfr_copysign (third argument), mpfr_signbit and mpfr_set (second argument). For
instance, providing an argument of type void * instead of mpfr_ptr or mpfr_srcptr
will yield a compilation failure. Note that this issue does not exist in C++,
which does not support such implicit conversions. Moreover, the mpfr_set macro
evaluates its second argument twice (reported by David McCooey), which is
incorrect if this evaluation has side effects. This is fixed by the macros patch
(with testcases). Macros for the custom interface, which are explicitly documented
as provided, do not follow these rules; the patch clarifies this point in the MPFR
manual.
Corresponding changesets in the 4.1 branch: 14468, 14469.
11 The test programs tset_si and tset_sj fail if MPFR_USE_NO_MACRO is defined (e.g.,
via -DMPFR_USE_NO_MACRO in CFLAGS). This is fixed by the tset_sij patch.
Corresponding changeset in the 4.1 branch: 14470.
12 The mpfr_get_str_ndigits function may raise the inexact flag. In a very reduced
exponent range (e.g. in which the result would not be representable as a MPFR
number), it has undefined behavior: it may return an incorrect value, crash, or
loop, taking more and more memory. This is fixed by the get_str_ndigits patch,
which also updates the tests to check these issues.
Corresponding changeset in the 4.1 branch: 14490.
13 The code for the formatted output functions (mpfr_printf, etc.) contains an
incorrect assertion, checked only in debug mode, i.e. when MPFR has been
configured with --enable-assert; this assertion failure occurs when the integer 0
(of either a native type or mpfr_prec_t with the length specifier P) is output
with the precision field equal to 0, i.e. when the corresponding string to output
is empty. Otherwise, there should be no side effects since the code is actually
valid in this case; but since the code incorrectly instructs the compiler that
some variable cannot be 0, there might be an issue with some optimizations (very
unlikely, though). This bug is fixed by the vasprintf-prec-zero patch, which also
provides testcases.
Corresponding changesets in the 4.1 branch: 14524, 14525.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
Historically, the MD5 checksums in our LFS files serve as a protection
against broken downloads, or accidentally corrupted source files.
While the sources are nowadays downloaded via HTTPS, it make sense to
beef up integrity protection for them, since transparently intercepting
TLS is believed to be feasible for more powerful actors, and the state
of the public PKI ecosystem is clearly not helping.
Therefore, this patch switches from MD5 to BLAKE2, updating all LFS
files as well as make.sh to deal with this checksum algorithm. BLAKE2 is
notably faster (and more secure) than SHA2, so the performance penalty
introduced by this patch is negligible, if noticeable at all.
In preparation of this patch, the toolchain files currently used have
been supplied with BLAKE2 checksums as well on
https://source.ipfire.org/.
Cc: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremeripfire.org>
Most of these files still used old dates and/or domain names for contact
mail addresses. This is now replaced by an up-to-date copyright line.
Just some housekeeping... :-)
Signed-off-by: Peter Müller <peter.mueller@link38.eu>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
