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.

 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.

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

However if I understand your point... is it that one could make an
alternative API over mpn with equal functionality as mpz_t? If it
possible, how hard would you estimate such a thing could be? And in
final, if there was such thing, would you add it to gmp?


best regards,
Nikos