State of PRNG code in GMP

[Torbjörn Granlund]

nisse at lysator.liu.se (Niels Möller) writes:

  It's a constraint on what the algorithm internal struct can look like,
  e.g., it can't have internal pointers (but it could have offsets). So
  not necessarily a show-stopper, but we should be aware when designing
  the interfaces.

The latest code added a copy function pointer and removed the datasize
field.  We should probably also have a cleanup function pointer.

  I do see some usecases for copying, to be able to save generator state
  and restart in the same state later. It may even be useful to be able do
  save generator state to disk, if you want to write periodic
  "checkpoints" for an algorithm that needs to run for a long time.

Oh, so serialising seed + buffered data would be useful.  Another
algorithm specific pointer.  :-)

(We could allow that part to be defined only for certain algorithms.  If
we define the interface as int gmp_prng_getstate(buf, const gmp_prng_t*)
and document that iff it returns non-zero the serialising worked.)

-- 
Torbjörn
Please encrypt, key id 0xC8601622