State of PRNG code in GMP

Niels Möller nisse at lysator.liu.se
Wed Jun 3 12:07:50 UTC 2020


tg at gmplib.org (Torbjörn Granlund) writes:

> /* PRNG algorithm specific data for any constants, buffered random bits, or
>    other state.  The _mp_data field should typically point to a algorithm
>    specific struct.  The _mp_datasize field is used by generic code for
>    de-allocating and copying a gmp_prng_t in an algorithm agnostic manner.  */
> struct appdata {
>   void* _mp_data;
>   size_t _mp_datasize;
> };

Does generic code really need to copy the algorithm specific data?

> /* Generic PRNG init function.  Is this really a good idea?  A problem is that
>    this will pull in all PRNG code into a binary which uses just one
>    algorithms.  It even pulls in mpz functions in a mpn-only program if any
>    PRNG uses mpz. */

I'd prefer to not have it. I think it's rare to initialize with an
algorithm enum selected at run time.

And the application that wants that will likely not get the enum value
out of the blue, but have a list of known/supported values mapped to
command line arguments or the like. So then it's not much extra work for
the application to have call the right initializer from it's own switch
statement.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.


More information about the gmp-devel mailing list