On 30 July 2016 at 02:52, Victor Stinner <victor.stinner@gmail.com> wrote:
2016-07-29 17:37 GMT+02:00 Nick Coghlan <ncoghlan@gmail.com>:
Ok, but imagine that you use the "expensive" GRNG_RANDOM (/dev/random rather than /dev/urandom). A first call returns 4000 bytes of "high quality" random bytes, but user requested 4096 bytes and the second call fails.
I'd say in the non-EINTR case with GRNG_RANDOM it would be reasonable to return a short read. So folks using that flag would need a Python-level loop, but folks using the kernel's CSPRNG wouldn't.
Do you mean return the 4000 bytes and *ignores* the error?
I'm not clear on the ways that GRNG_RANDOM can fail (other than EINTR), so I'm not sure. I just think we have a fair bit of leeway for the behaviour of that flag to be less user friendly than the default behaviour, since the "may block unexpectedly during normal execution" behaviour is already inherently user unfriendly :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia