Extending the mpn interface

[Niels Möller]

bodrato at 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.