mpz_limbs interface
    Niels Möller 
    nisse at lysator.liu.se
       
    Tue Jan 21 15:09:35 UTC 2014
    
    
  
Zimmermann Paul <Paul.Zimmermann at 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.
    
    
More information about the gmp-devel
mailing list