Torbjörn Granlund tg at
Fri Aug 21 06:56:32 UTC 2015

"Marco Bodrato" <bodrato at> writes:

  Maybe we can "promise" the right type, by adding an explicit cast?
  SIZ((mpz_srcptr) NUM(op2))
Except that we should cast op2, not NUM(ops).

I am not sure Marc's reasoning is accurate, nor am I suggesting it is
not, I've forgotten this level of detail of the C standard.  I am not
too enthusiastic about passing the wrong type, but if we add casts both
when going to &mpq and when going back to &mpz, I cannot see how that
could break with a conforming compiler.

  > > (We might consider adding mpf_cmp_z too, at least in a simple-minded
  > > manner, to keep the GMP interface as orthogonal as possible.)
  > Adding new mpf_t functions might confuse the message that people should
  > use mpfr...
  We can silently add it to the manual without claiming it in the release
  announce :-)
Or deny that we added it?

  A tenth of lines of code should be enough, shouldn't it?
  mpf_cmp_z (mpf_srcptr u, mpz_srcptr v) __GMP_NOTHROW
    mpf_t vf;
    mp_size_t size;
    SIZ (vf) = size = SIZ (v);
    EXP (vf) = size = ABS (size);
    /* PREC (vf) = size; */
    PTR (vf) = PTR (v);
    return mpf_cmp (u, vf);
It looks about right.  The code for mpf_set_z should provides a pattern,
except that its conditionally truncattion is not needed.

Please encrypt, key id 0xC8601622

More information about the gmp-devel mailing list