• Bug#1057355: libmpfr6: major formatted output function bugs with %c and

    From Vincent Lefevre@21:1/5 to Paul Gevers on Sun Mar 23 11:40:01 2025
    Hi Paul,

    On 2025-03-23 11:17:52 +0100, Paul Gevers wrote:
    Hi Vincent,

    On Fri, 15 Dec 2023 04:53:51 +0100 Vincent Lefevre <vincent@vinc17.net> wrote:
    On 2023-12-03 22:13:03 +0100, Vincent Lefevre wrote:
    I've reported the following bug in the MPFR mailing-list. I think
    I've fixed the issues on the MPFR side in master, but MPFR is still affected by the bug on the GMP side (gmp_vasprintf):
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057344

    The gmp_vasprintf function is actually correct (but its documentation
    is not; and it is gmp_sprintf that is incorrect, which is not a
    problem for MPFR). I've fixed the remaining bugs in MPFR.

    In which version is this fixed? 4.2.2?

    Yes, it is fixed in 4.2.2, but this assumes that GMP does not use
    its buggy vsnprintf replacement (i.e. it uses either the system
    vsnprintf function or the replacement that was patched one year
    ago in the development branch). I suppose that for Debian, the
    system vsnprintf function is used on all platforms (this is decided
    at GMP build time, after some tests for C conformance in GMP's
    configure script).

    If the buggy vsnprintf replacement is used, the MPFR testsuite would
    fail. I've put the following section in the INSTALL file about such
    a failure:

    ------------------------------------------------------------------------ tfprintf and tsprintf failures in check_null --------------------------------------------

    If you get the failures

    $ ./tfprintf
    Error in test #40: mpfr_vfprintf printed 1 characters instead of 4

    $ ./tsprintf
    Error in check_null, i = 0
    expected r = 1, s = { 0, 0, 1 }
    got r = 0, s = { 0, 1, 1 }

    the cause is probably that GMP uses a buggy vsnprintf replacement.
    The reason GMP uses its own vsnprintf replacement is that during
    configure, it detected that the vsnprintf function from the C library
    is buggy. But the replacement from GMP 6.3.0 and below also has its own
    bugs. This means that using the formatted output functions with %c and
    the value 0 will yield an erratic behavior.

    For the above issue, this is fixed in the GMP development branch:

    https://gmplib.org/repo/gmp/rev/4ac76064639e

    You can have details at
    https://gmplib.org/list-archives/gmp-bugs/2023-December/005420.html
    https://gitlab.inria.fr/mpfr/mpfr/-/commit/390e51ef85

    These tests can be skipped by defining the MPFR_TESTS_SKIP_CHECK_NULL macro, but you should rather get a fixed vsnprintf replacement. ------------------------------------------------------------------------

    --
    Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
    100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
    Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fiona Ebner@21:1/5 to All on Fri Apr 11 16:40:02 2025
    Hi,

    On Sun, 23 Mar 2025 11:37:45 +0100 Vincent Lefevre <vincent@vinc17.net>
    wrote:
    Hi Paul,

    On 2025-03-23 11:17:52 +0100, Paul Gevers wrote:
    Hi Vincent,

    On Fri, 15 Dec 2023 04:53:51 +0100 Vincent Lefevre <vincent@vinc17.net> wrote:
    On 2023-12-03 22:13:03 +0100, Vincent Lefevre wrote:
    I've reported the following bug in the MPFR mailing-list. I think
    I've fixed the issues on the MPFR side in master, but MPFR is still affected by the bug on the GMP side (gmp_vasprintf):
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057344

    The gmp_vasprintf function is actually correct (but its documentation
    is not; and it is gmp_sprintf that is incorrect, which is not a
    problem for MPFR). I've fixed the remaining bugs in MPFR.

    In which version is this fixed? 4.2.2?

    Yes, it is fixed in 4.2.2, but this assumes that GMP does not use
    its buggy vsnprintf replacement (i.e. it uses either the system
    vsnprintf function or the replacement that was patched one year
    ago in the development branch). I suppose that for Debian, the
    system vsnprintf function is used on all platforms (this is decided
    at GMP build time, after some tests for C conformance in GMP's
    configure script).

    If the buggy vsnprintf replacement is used, the MPFR testsuite would
    fail. I've put the following section in the INSTALL file about such
    a failure:

    ------------------------------------------------------------------------ tfprintf and tsprintf failures in check_null --------------------------------------------

    If you get the failures

    $ ./tfprintf
    Error in test #40: mpfr_vfprintf printed 1 characters instead of 4

    $ ./tsprintf
    Error in check_null, i = 0
    expected r = 1, s = { 0, 0, 1 }
    got r = 0, s = { 0, 1, 1 }

    the cause is probably that GMP uses a buggy vsnprintf replacement.
    The reason GMP uses its own vsnprintf replacement is that during
    configure, it detected that the vsnprintf function from the C library
    is buggy. But the replacement from GMP 6.3.0 and below also has its own
    bugs. This means that using the formatted output functions with %c and
    the value 0 will yield an erratic behavior.

    For the above issue, this is fixed in the GMP development branch:

    https://gmplib.org/repo/gmp/rev/4ac76064639e

    You can have details at
    https://gmplib.org/list-archives/gmp-bugs/2023-December/005420.html
    https://gitlab.inria.fr/mpfr/mpfr/-/commit/390e51ef85


    I was able to successfully build mpfr4_4.2.2-1.dsc using sbuild. I can
    see that "make check" is invoked as part of that and the "tfprintf" and "tsprintf" test cases pass. So it seems like this bug can be closed.

    Best Regards,
    Fiona

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)