mini-gmp

[Zimmermann Paul]

       Niels,

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

we'll do that during our MPFR/MPC workshop next week.

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

MPFR uses that only in "make check", to check all allocations are clean.
I've disabled it when configuring with mini-gmp.

Paul