mini-gmp

[Niels Möller]

Zimmermann Paul <Paul.Zimmermann at inria.fr> writes:

> I'm not aware of those functions. Having public functions to access the mpz_t
> fields would be useful.

They will be in gmp-5.2, to be released soon. It would be useful if you
could check the documentation and/or implementation of the mpz_limbs_*
functions, and say if they satisfy mpfr's needs.

> Btw, in gmp_xrealloc_limbs you call gmp_reallocate_func with old_size=0,
> which makes the memory management check in the MPFR tests fail. Please
> could you fix that?

This is a documented incompatibility. See mini-gmp/README:

  The REALLOC_FUNC and FREE_FUNC registered with
  mp_set_memory_functions does not get the correct size of the
  allocated block in the corresponding argument. mini-gmp always
  passes zero for these rarely used arguments.

I'm fairly sure I asked about this at the time, and potential users of
mini-gmp saw no problem with it.

I actually think this GMP interface is subtly broken, and I think we
should do the same change also to GMP at some point. E.g, the
mpz_get_str docs say

     If STR is `NULL', the result string is allocated using the current
     allocation function (*note Custom Allocation::).  The block will be
     `strlen(str)+1' bytes, that being exactly enough for the string and
     null-terminator.

But in unlikely cases, the allocated size will actually be
strlen(str)+2, so the user can't pass the correct old_size when
deallocating it. And I see no nice and clean way to fix this with the
current API.

If mpfr uses the old_size argument only for sanity checks, I'd suggest
simply disabling that check under USE_MINI_GMP. If you really need the
old_size value, we have to think harder about it.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.