[PATCH] Custom random number generation function.

[Pedro Gimeno]

Laurent Fousse wrote:
> I can change my patch to name the proposed generator "stateless"
> instead of custom. Would it be accepted in GMP, if it is properly
> documented to be stateless? Or would you rather expose the full struct
> to the user?

I think that the addition of a particular case that can be covered by
the general case is not the way to go.

Exposing the full struct is a possibility, but such struct should
preferably be kept opaque and only expose an interface to set the
functions it contains. Example:

void
gmp_randinit_generic (gmp_randstate_t    rstate,
                      gmp_randseed_fn_t  randseed_fn,
                      gmp_randget_fn_t   randget_fn,
                      gmp_randclear_fn_t randclear_fn,
                      gmp_randiset_fn_t  randiset_fn);

where the function pointer types are defined in gmp.h, of course, and
documented about their prototype and purpose. The RNG_STATE macro should
be published and documented as well.

Maybe there should be two more reserved parameters for the import and
export functions, for when these are implemented. But it could be
possible to add another function that includes them in future, so that's
probably not necessary. Opinions welcome.

The GMP code should also be reworked so that gmp_randclear deals with
freeing the RNG_FNPTR member and the whole rstate and preventing the
individual custom implementations (randclear_lc, randclear_mt) from
doing that as they are doing now. Furthermore, the initialization
functions should be reworked so that instead of using constant structs
for the RNG_FNPTR member, they allocate it, or alternatively set a flag
indicating that it must not be deallocated, which is honored by
gmp_randclear.

The structure of gmp_randstate_t is a mess that will hopefully be solved
when binary compatibility is decided to be thrown away in one release,
if that ever happens. Long ago, it was proposed to keep a list of legacy
things to clean up if that ever happened. I don't know if such a list
exists, but a cleanup of gmp_randstate_t should definitely be in it if
it isn't already.

As for the acceptance of such a patch, I can't speak for that.

-- Pedro Gimeno