Paul.Zimmermann at inria.fr
Sat Jan 18 09:48:47 UTC 2014
> > 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
> 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.
More information about the gmp-bugs