GMP API

[Nikos Mavrogiannopoulos]

Torbjorn Granlund wrote:
>   > The first thing to understand is that it is not sufficient to ensure
>   > that destination variables space needs can be met; internal scratch
>   > space needs might also trigger out-of-memory conditions. 
>   
>   My point is on having errors for these conditions, rather than adopting
>   a specific way.
> Ehum?

There are more ways to indicate errors than the one used by libgcrypt.
One could return error codes as well. My point is to indicate errors
rather than saying do what libgcrypt does.

> 
>    These needs
>   > are far from easy to compute beforehand, even if we tried to supply such
>   > an interface.  (And if one computed them beforehand, one would have a
>   > race condition for VM.)
>   > It would slow down and complicate GMP if we tried to flag ourselves out
>   > of error situations like memory allocation problems.  Many internal
>   > calls would need to be checked, which would require redesign of many
>   > internal function, to add an error return mechanism.
>   
>   I believe the benefits of having something like this, outweigh the
>   costs. However I have different interests and point of view.
>   
> You mean, 3 man years for me rewriting GMP outweigh the costs for the
> gcrypt developers spending a week rewriting things to use mpn low level
> routines?  8-)

This is what I understand, and why I made the question below. If the
mpz_t functionality needs 3 man-years to be fixed, why you think using
mpn would take less? Isn't mpz written over mpn?

And to repeat my question, if that thin layer existed would you make it
part of gmp?


>   > For crypto usages, it should not be very hard to use documented mpn
>   > routines which do not allocate space.  Unfortunately, we don't currently
>   > document O(n^2) multiplication or division functions, only more
>   > primitive and more general functions.  For cryptographic applications,
>   > O(n^2) mul and div/mod should be what one needs.
>   
>   I don't believe this is a solution. Using obscure or more low level
>   functions, for crypto. A programmer should not need to deal with
>   internal details, since it not only requires more work from him, but
>   mainly it adds complexity to a code that should be simple (crypto code).
>   Having safe code, shouldn't imply having more low level code.
>   
> I suppose I have the opposite view here.  Interfacing at a high level
> brings in more code, 

More code to a single place, which is good.

> interfacing just to mpn_add_n, mpn_sub_n,
> mpn_addmul_1, mpn_mul_1 and a few more, would me feel much more
> confident about the crypto code.  Also, there is a lot of speed gain
> from using low-level functions for the small operand one uses in crypto.

I don't see why someone who is implementing crypto should do more work
than someone who isn't. And it is not about crypto, but rather about
applications that need error recovery from out of memory.

regards,
Nikos