[4.1.1 regression] mpfr_custom_get_kind const argument

(First reported at https://github.com/CGAL/cgal/issues/7064)

The macro now (2a7e5a8a) starts with

#define mpfr_custom_get_kind(x)                                         \
  __extension__ ({                                                      \
    mpfr_ptr _x = (x);                                                  \

However, the function prototype is

__MPFR_DECLSPEC int mpfr_custom_get_kind (mpfr_srcptr);

Note the const difference between the 2 types. Should the macro be fixed to use mpfr_srcptr?

yes probably:

--- a/src/mpfr.h
+++ b/src/mpfr.h
@@ -1064,7 +1064,7 @@ __MPFR_DECLSPEC int mpfr_total_order_p (mpfr_srcptr, mpfr_srcptr);
 #if __GNUC__ > 2 || __GNUC_MINOR__ >= 95
 #define mpfr_custom_get_kind(x)                                         \
   __extension__ ({                                                      \
-    mpfr_ptr _x = (x);                                                  \
+    mpfr_srcptr _x = (x);                                               \
     _x->_mpfr_exp >  __MPFR_EXP_INF ?                                   \
       (mpfr_int) MPFR_REGULAR_KIND * MPFR_SIGN (_x)                     \
       : _x->_mpfr_exp == __MPFR_EXP_INF ?                               \

This compilation bug is also impacting the development version of Fedora Linux: https://bugzilla.redhat.com/show_bug.cgi?id=2144197.

I agree. And the testsuite will need to be improved to detect this kind of issue.

changed title from mpfr_custom_get_kind const argument to [4.1.1 regression] mpfr_custom_get_kind const argument

mentioned in commit 0ce17bae

mentioned in commit 3cd39bc0

I've patched the master and 4.1 branches (see mentioned commits). I will do more extensive tests.

Do you confirm that this completely fixes the CGAL related builds?

Since 4.1.1 is new and may make the build of user code fail, I think that we should do a release of 4.1.2 with this fix. Any comment?

Since 4.1.1 is new and may make the build of user code fail, I think that we should do a release of 4.1.2 with this fix.

agreed, but maybe wait for mid-December, in case any other issue is found in the meantime (and publish the patch on the 4.1.1 page)?

Hi Vincent, Paul (@vlefevre, @zimmerma), do you plan to publish 4.1.2 soon? The current situation for downstream projects, as far as I know is:

• Fedora 38 (Rawhide) ships mpfr-4.1.1-p1,
• ArchLinux also ships mpfr-4.4.1-p1,
• I have warned the Debian maintainer of mpfr, and they stay stuck for 4.1.0 for now,
• as for Homebrew, they decided not to update to mpfr-4.1.1 (because they find inconvenient to ship patches when a release is about to be published), and wait for mpfr-4.1.2 (here is the closed, not merged, pull-request).

More downstream:

• vcpkg has a pull-request to update from 4.1.0 to 4.1.1-p1, but it is stalled.
• Conda Forge also has a pull-request to update from 4.1.0 to 4.1.1, but without the p1 patch, stalled as well.
• Conan is still with mpfr-4.1.0, and struggling with the compatibility of its recipe with Conan 2.0.

There was an announcement for 4.2.0-rc1 on Tuesday.

I'm going to publish the patch on the 4.1.1 page, but I fear that most distributions will upgrade to 4.1.1 without noticing it, while they will not detect the bug.

(I also hope to release 4.2.0 soon, but this may take some time if issues are found.)

I've posted the patch on the GNU MPFR 4.1.1 page. The tests on various platforms still succeed.

closed

There was an announcement for 4.2.0-rc1 on Tuesday.

yes downtream projects should switch to 4.2.0 when it is ready (we are currently intensively testing it)