This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients jasujm, neologix, pitrou, python-dev, serhiy.storchaka, vstinner
Date 2013-12-17.14:00:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1387288842.47.0.511269602404.issue17976@psf.upfronthosting.co.za>
In-reply-to
Content
I played with fullwrite.c and now think that the fix is incomplete. fwrite() may succeed to write data into the buffer, but you may get the error on fflush() or fclose().

Try attached fullwrite2.c: fwrite() succeed (written=len, errno=result=0), whereas fclose() fails. If you enable fflush(), it will also fail.

Output:
---
fwrite(hello
) => 6 bytes written/6 [errno=0, ferror=0]
fclose() => -1 [errno=28]
---

The complete fix is maybe to write fflush() before fclose(), or at least raise an exception if fclose() returns a non-zero result. Correctly, file.close() returns a number in case of an error...

But now comes the question of backward compatibility, may such change "break" applications? It's maybe a nice thing to "break" applications if it warns users that they are going to loose data (USB key full, cannot write the whole important document!).
History
Date User Action Args
2013-12-17 14:00:42vstinnersetrecipients: + vstinner, pitrou, neologix, python-dev, serhiy.storchaka, jasujm
2013-12-17 14:00:42vstinnersetmessageid: <1387288842.47.0.511269602404.issue17976@psf.upfronthosting.co.za>
2013-12-17 14:00:42vstinnerlinkissue17976 messages
2013-12-17 14:00:41vstinnercreate