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 loewis
Recipients
Date 2007-02-09.23:14:41
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
There seem to be multiple problems here. AFAICT,

print >>f, 3

fails on both Linux and OSX. This is because this uses fprintf to put out the number, which, in turn, returns -1. This result is ignored; instead Python expects ferror() to be set. However, ferror doesn't get set.

For printing strings, fwrite is used. On both Linux and OSX, fwrite will return 0. On Linux, in addition, ferror gets set; on OSX, it doesn't.

Reading C99, I can't figure out which of these systems is behaving correctly in what cases. The definition of ferror is that it returns the "error indicator" of the stream, and only fseek, fputc (+putc), and fflush are explicitly documented to set the error indicator. However, the error indicator is also documented to be set that it "records whether a  read/write error  has  occurred", and write is documented to return a number smaller than the requested only if an error occurred. Likewise, fprintf is document to return an negative value "if an  output  or  encoding error occurred."

Putting these all together, ISTM that both Linux and OSX implement fprintf incorrectly. To work around, Python could check the result of fprintf and fwrite in all places; this might become a large change.
History
Date User Action Args
2007-08-23 14:51:46adminlinkissue1653416 messages
2007-08-23 14:51:46admincreate