nmav at gnutls.org
Tue Jun 22 20:39:20 CEST 2010
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.
> 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?
More information about the gmp-devel