bodr...@mail.dm.unipi.it writes: > 1) Zero-padding. _mpz_read_limbs_n overwrite the unused area with zeros, > _mpz_modify_limbs does not. Why? I think they should be the same function: > inline const mp_limb_t * _mpz_read_limbs_n (mpz_ptr x, mp_size_t n) > { return _mpz_modify_limbs (x, n); }
Maybe. My thinking was that since _mpz_modify_limbs returns a writable pointer, the caller can zero pad whenever that is appropriate. While the caller of _mpz_read_limbs_n shouldn't write any limbs there. Actually, my current code doesn't yet use the _mpz_write_limbs and _mpz_modify_limbs. > 2) _mpz_done_limbs should take care of the sign. Makes sense. I have no strong opinion of how to handle signs. > 3) _mpz_init_mpn (maybe mpz_roinit_n is a better name) sets _alloc=0. I > remember you suggested this as a mark for read-only mpzs, but it is > currently unsupported by the library (with --enable-assert). I'd suggest > x->_mp_alloc = ABS (xs); I would expect that no gmp function that gets an mpz_srcptr as argument ever examines _mp_alloc. If I'm wrong about that, I agree one should put some other value in _mp_alloc. > 4) I'm not sure I understand the need for _mpz_copy_limbs, it can be > obtained with mpz_export (padding excepted). One use case: I represent coordinates as an array of 3*n limbs (each coordinate is in Z_p, and p is n limbs). I want to assing coordinates from an mpz_t. In this case, padding *is* necessary, so it's convenient with a function which copies the value to the full {xp, n} area. But it could of course be implemented on top of _mpz_read_limbs, mpn_size and mpn_zero. And I feel quite strongly that mpz_import and mpz_export are too complicated for the purpose of mpn/mpz interoperation. > 5) I'm not sure I understand the need for _mpz_cmp_limbs. Consider the same data structure, and I want to compare one of the coordinates to an mpz_T. E.g., I have an ecdsa_verify which ends with return (_mpz_cmp_limbs (signature->r, P, ecc->size) == 0); where signature contains two mpz_t values supplied by the user, and P is an ecc point using mpn-level representation. But if we want to aim for a minimal set of _mpz_* functions, and let applications implement whatever is convenient for them on top of the primitives, then _mpz_cmp_limbs is not essential. 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 http://gmplib.org/mailman/listinfo/gmp-devel