[pycrypto] Run test suite with /dev/random

[Sebastian Ramacher]

On 01/27/2012 07:13 PM, Dwayne C. Litzenberger wrote:
> On Fri, Jan 20, 2012 at 05:20:57PM +0100, Sebastian Ramacher wrote:
>> Nevertheless there is still an issue in pycrypto left. The assumption that
>> read always returns the amount of data requested if there is enough available
>> is not true. If the process is interrupted by a signal read will return less.
>> At least that's the case for Python3.
> 
> That assumption is *correct*.  A Python file object's read() method always
> returns the requested amount of data, except in two cases:
> 
>     1. Non-blocking I/O is selected; or
>     2. End-of-file is reached.
> 
> You are confusing this with the read(2) syscall, which *can* return fewer bytes
> than requested if the process receives a signal.
> 
> Here's the relevant Python documentation:
> 
>> file.read([<size>])
>>
>>     Read at most <size> bytes from the file (less if the read hits EOF    
>> before obtaining <size> bytes). If the <size> argument is negative     or
>> omitted, read all data until EOF is reached. The bytes are     returned as a
>> string object. An empty string is returned when EOF     is encountered
>> immediately. (For certain files, like ttys, it makes     sense to continue
>> reading after an EOF is hit.) Note that this     method may call the
>> underlying C function fread() more than once in     an effort to acquire as
>> close to <size> bytes as possible. Also     note that when in non-blocking
>> mode, less data than was requested     may be returned, even if no <size>
>> parameter was given.
>>
>>     Note: This function is simply a wrapper for the underlying fread()     C
>> function, and will behave the same in corner cases, such as     whether the
>> EOF value is cached.
>>
>> -- http://docs.python.org/library/stdtypes.html#file-objects

There is no file object anymore. The I/O stack got rewritten in Python 3. If
open would be called without buffering=0, all the assumptions would be correct
again (and one would have fread like behavior). But since buffering equals 0,
open returns a FileIO instance. And FileIO.read just behaves as the underlying
syscall which is read(2). [1, 2]

Kind regards,

[1] http://docs.python.org/py3k/library/io.html#raw-i-o
[2] http://docs.python.org/py3k/library/io.html#io.RawIOBase