Zimmermann Paul <paul.zimmerm...@inria.fr> writes: > we have looked at the mpz_limbs interface,
Thanks for the review. > it seems it won't be sufficient for > our needs in MPFR. Consider for example the following function, which > generates nbits random bits into mp[]: I see. In this particular case, I think the right gmp interface change is to add mpn_urandomb and mpn_rrandomb (similar to current mpn_random and mpn_random2, but with a randstate argument). If I understand this correctly, the main obstacle is that random number internals use mpz functions, which is an undesirable dependency for mpn functions. Any other problematic cases? > MPFR_ASSERTN (nbits >= 1); > /* To be sure to avoid the potential allocation of mpz_urandomb */ > ALLOC(z) = SIZ(z) = MPFR_PREC2LIMBS (nbits); > PTR(z) = mp; [...] > mpz_urandomb (z, rstate, nbits); I think this is brittle, and I don't think this style should be officially supported in the public gmp interface. mpz_urandomb is not included in mini-gmp, but if you, e.g., try the same with other functions, it will most likely break with mini-gmp which assigns many of the output parameters using mpz_swap. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
