Branko Äibej <[EMAIL PROTECTED]> writes:
> >Or gstein has suggested that apr_generate_random_bytes() can grow a
> >new flag, indicating urandom is preferred.
>
> That would look weird to APR users on systems that have never heard of
> /dev/random and /dev/urandom (several come to mind, all of which use \
> for the path separator).
Yeah. Anyway, the question of random vs unrandom is an implementation
detail, it doesn't belong in interface. The *real* problem here is
the blocking behavior -- which is visible to callers and is
appropriate to address in the interface, maybe like this:
/**
* Generate random bytes.
* @param buf Buffer to fill with random bytes
* @param length Length of buffer in bytes (becomes apr_size_t in APR 1.0)
* @param dont_block Disallow a long wait for high-quality random
* data, even if doing so lowers the randomness of the result.
*/
apr_generate_random_bytes(buf, length, dont_block);
On systems where blocking is not a problem, the `dont_block' parameter
would simply have no effect. But the question is, are there systems
where blocking is a problem, but there's nothing we can do about it?
If so, dont_block would be a lie on such systems, unless we fell back
to some *really* unreliable method like pointer values XOR time of
day...
I don't know if there are such systems, though. Anyone?
-K
