Marko Rauhamaa <ma...@pacujo.net> writes: > Let me mention a related problem I ran into a couple of weeks ago. > Linux's standard C library (glibc) implements fread(3) differently in > RHEL 5 and RHEL 6/7. In RHEL 5, it blocks in a loop until it has read in > the desired number of records. In RHEL 6 and 7, it appears to block > until it can return at least one whole record.
By my reading of the POSIX standard, that latter behavior would be incorrect. The "RETURN VALUE" section of the POSIX description for fread() starts: Upon successful completion, fread() shall return the number of elements successfully read which is less than nitems only if a read error or end-of-file is encountered. ... If in whatever version of glibc comes with RHEL 6/7, it is the case that a call to fread() can return less than the desired number of records, and you have not reached EOF, and no read error has occurred, that would be a serious bug. The world is full of C programs that call fread() and fwrite() without wrapping them in defensive maybe-I-didn't-get-everything loops. >> Am I missing something? There seem to be some primitive IO facilities >> in Python 3 that make a distinction between blocking and non-blocking >> mode, but that distinction doesn't seem to be available when I just >> call open(). Since I wrote this, I have discovered and read PEP-3116, and using that as a road-map to understanding the Python 3 documentation it is now clear to me that in Python 3, if you have not gone out of your way to enable non-blocking, a call to the .write() method on any object that might normally be returned by a call to open(), will always write _all_ of your data (or raise an exception). There is never any need for a defensive loop. As further evidence that this is the case, note that PEP-3116 says right at the end of its "Rationale and Goals" section: ... Programmers who don't want to muck about in the new I/O world can expect that the open() factory method will produce an object backwards-compatible with old-style file objects. Since old-style file objects didn't return a count, this goal can only be achieved if programmers are safe in _ignoring_ that count in Python 3. I am relieved to discover that when I am finally able to port my Python code from Python 2 to Python 3, I will not have to worry that .write() might perform an incomplete write where it previously did not. -- Alan Bawden -- https://mail.python.org/mailman/listinfo/python-list
