tg at gmplib.org
Fri Nov 25 13:39:54 UTC 2016
nisse at lysator.liu.se (Niels Möller) writes:
Sounds reasonable to me. But then I'd also consider adding a return
value, returning one if the inputs were coprime (gcd == 1), otherwise
zero. Would be useful for mpz_invert.
That, unlike the user proposal, is a change which breaks source
compatibility. I suppose it also implies a slight computation overhead
to check size + low limb for the return value.
This sort of things probably below here:
(Adding an integer return value is a breaking ABI change in theory, but
not really in practice, as far as I understand).
The type of the gcd function change, which breaks e.g. user function
pointers to these functions.
I am busy with large changes for what I think of as GMP 7.
o Symbol visibility for .so lib speed and size. This is a change which
will make GMP application incomatible if they play with GMP's
internals. (I am not being fascist and hide everything we consider
o Perhaps leave our exact-CPU override of config.guess and replace it
with some option --enable-cpu=skylake or --enable-cpu=all (=fat) or
--enable-cpu=native. This breaks the build process people might be
used to. The main motivation for this change is that libtool is now
not abe to do its job, it requires the plain config.sub names.
o Add some wider scalar type (e.g. long long) and mpz _uj functions.
Perhaps the same release would be a good place for improving the API in
slightly incompatible ways?
I won't be ready with my changes until sometimes in the (northern
hemisphere) spring. There is no hurry with breaking the API. :-)
Please encrypt, key id 0xC8601622
More information about the gmp-devel