nisse at lysator.liu.se
Fri Jan 17 07:31:15 UTC 2014
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
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
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.
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
More information about the gmp-bugs