mpz_gcd_ext(NULL, ...)

[Torbjörn Granlund]

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:
https://gmplib.org/devel/incompatibility.html

  (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
  "private".)

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. :-)


-- 
Torbjörn
Please encrypt, key id 0xC8601622