STINNER Victor added the comment: > But EINVAL should also be checked for to make sure the system call was > invoked with proper parameters.
py_getrandom() calls Py_FatalError() or raises an OSError on EINVAL. The error is not silently ignored. > My builds of Python 3.5.0.X (don't recall whether X was a late Beta or > release candidate) were core dumping because Python was making that syscall > but not checking for EINVAL, Py_FatalError() calls abort(). Usually, operating systems dump a core dump in this case. But it is the expected behaviour. Python now refuses to start if the OS random number generator doesn't work. There are similar checks on the system and monotonic clocks for example. > ... and thus assuming the call was valid, when it was not. Ah! Finally you explain the problem :-) I wrote py_getrandom() for Linux. I didn't expect other operating systems to implement the getrandom() syscall. I hardcoded the flags (0) for example. py_getrandom() calls directly the syscall, because I like the new cool getrandom() syscall of Linux: it avoids the need of a private file descriptor. It would be much better to call a function of the C library, but the GNU C library didn't expose the function yet... On Solaris, the function is available in C, no need to call directly the syscall. It would be better to call the C function, and check if it's available in configure. Can you please try remove_get_entropy.patch + urandom_solaris.patch? ---------- Added file: http://bugs.python.org/file40437/getrandom_solaris.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25003> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
