GMP API

[Torbjorn Granlund]

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

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

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

  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?

Our view within the GMP project is that we will provide an improved,
better documented mpn layer for your types of usages.

-- 
Torbjörn