![[MPFR]](../mpfr100.png){kind=small}
The fondue savoyarde release.
MPFR 4.2.0 requires GMP 5.0 or higher.
Note: the bug-fix release MPFR 4.2.1 is available. Please upgrade!
The MPFR 4.2.0 source can be downloaded in the following archive formats:
Each tarball is signed by Vincent Lefèvre. This can be verified using the DSA key ID 5831D11A0D4DB02A; this key can be retrieved with:
gpg --recv-keys 5831D11A0D4DB02A
or by downloading it from https://www.vinc17.net/pgp.html. The key fingerprint is:
A534 BE3F 83E2 41D9 1828 0AEB 5831 D11A 0D4D B02A
The signatures can be verified with:
gpg --verify file.asc
You should check that the key fingerprint matches.
MPFR is also available via third-party packages and ports.
The bugs listed below have been fixed (latest update: 2023-07-17). The patches are distributed under the same license as this version of MPFR, that is, the GNU Lesser General Public License (GNU Lesser GPL), version 3 or later.
The following instructions are for Linux and may be similar for other operating systems. You can apply the patches in several ways:
patch -N -Z -p1 < path_to_patches_filefrom the source directory. The -N option allows the patch command to ignore patches already applied. Because make's rebuild decisions are based on timestamps, the -Z option is highly recommended: it sets the modification time of the patched files from timestamps given in the patch file, thus avoiding unnecessary rebuilds that could need some development utilities (such as autoconf); for the special PATCHES file, this may generate a
Not setting timewarning, which you can safely ignore. If the -Z option is not available, you can also avoid the unnecessary rebuilds by using the --disable-maintainer-mode configure option later. Under Microsoft Windows, in addition to the above options, you may need the --binary option (this depends whether the end-of-lines have been converted when you downloaded the patch file). Also note that the --dry-run option does not work if the cumulative patch has some file listed several times.
With the first two ways, the PATCHES file is modified, so that one can know what patches have been applied, using the mpfr_get_patches function. Moreover a suffix is added to the version string, but note that for practical reasons, not all the files where the version appears are patched; thus one can also track applied patches with the MPFR_VERSION_STRING macro (header) and the mpfr_get_version function (library). However, if some patches are not applied or if patches are applied in a different order, then the patch command will fail to update some chunks, so that the suffix is not always reliable for patches.
Note: These patches are in unified diff format and some vendors' patch commands cannot deal with them; in this case, please use GNU patch (it may already be installed on your system, e.g. as /usr/local/bin/patch or gpatch).
Fixed bugs, with patches:
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.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).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.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.mpfr_reldiff bugs mentioned above, in particular). The tests-reuse patch adds a check of the sign of zero and contains other minor improvements.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.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.mpfr_snprintf (NULL, 0, "%.2147483648Rg\n", x);. This is fixed by the printf_large_prec_for_g patch, which also provides testcases.may be used uninitializedwarning 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.
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.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.See also the BUGS file. The Reporting Bugs section of the MPFR manual gives details on how to report new bugs.
Other bugs fixed in the 4.2 branch for the MPFR 4.2.1 release:
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).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.mpfr_cosu, mpfr_sinu, mpfr_tanu, mpfr_acosu, mpfr_asinu, mpfr_atanu and mpfr_atan2u.mpfr_cospi, mpfr_sinpi, mpfr_tanpi, mpfr_acospi, mpfr_asinpi, mpfr_atanpi and mpfr_atan2pi.mpfr_log2p1, mpfr_log10p1, mpfr_exp2m1, mpfr_exp10m1 and mpfr_compound_si.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).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.mpfr_custom_init_set).MPFR 4.2.0 has been successfully compiled and checked on the following platforms: