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 johansen
Recipients johansen, laca, pitrou
Date 2008-08-28.17:04:48
SpamBayes Score 1.265352e-06
Marked as misclassified No
Message-id <1219943150.49.0.641767477373.issue3014@psf.upfronthosting.co.za>
In-reply-to
Content
As I said before:

  check_and_flush calls ferror(3C) and then fflush(3C) on the FILE
  stream associated with the file object.  There's just one problem
  here.  If it finds an error that was previously encountered on the
  file stream, there's no guarantee that errno will be valid.
  Should an error be encountered in fflush(3C), errno will get set;
  however, the contents of errno are undefined should fflush()
  return successfully.

The problem is this:

The caller of check_and_flush() will check errno if check_and_flush
returns an error.  However, check_and_flush() checks two different error
sources.  If ferror() returns an error, you can't check errno, because
that routine doesn't set errno.  However, if fflush() returns an error,
it will set errno.

In its current form, no caller of check_and_flush() should check errno
if the check_and_flush doesn't return successfully, since there's no way
of knowing whether errno will be set or not.

That doesn't make a lot of sense to me, so I would probably re-write
this code.  However, since I'm not an expert in the inner workings of
the Python interpreter, it's hard for me to suggest just how to do this.
History
Date User Action Args
2008-08-28 17:05:50johansensetrecipients: + johansen, pitrou, laca
2008-08-28 17:05:50johansensetmessageid: <1219943150.49.0.641767477373.issue3014@psf.upfronthosting.co.za>
2008-08-28 17:04:49johansenlinkissue3014 messages
2008-08-28 17:04:48johansencreate