The following issue has been UPDATED.
======================================================================
http://austingroupbugs.net/view.php?id=87
======================================================================
Reported By: geoffclare
Assigned To: ajosey
======================================================================
Project: 1003.1(2008)/Issue 7
Issue ID: 87
Category: System Interfaces
Type: Error
Severity: Objection
Priority: normal
Status: Resolved
Name: Geoff Clare
Organization:
User Reference:
Section: fflush
Page Number: 844
Line Number: 28024
Final Accepted Text:
Resolution: Accepted
Fixed in Version:
======================================================================
Date Submitted: 2009-06-29 17:30 UTC
Last Modified: 2009-07-01 17:05 UTC
======================================================================
Summary: fflush and ungetc
Description:
_____________________________________________________________________________
OBJECTION Enhancement Request
Number 17
gwc:xxxxxxxxxxxxx Defect in XSH fflush (rdvk#
2)
[gwc fflush and ungetc] Fri, 12 Dec 2008 10:23:07
+0000
_____________________________________________________________________________
The descriptions of fflush() and fclose() state:
If the file is not already at EOF, and the file is one capable of
seeking, the file offset of the underlying open file description
shall be adjusted so that the next operation on the open file
description deals with the byte after the last one read from or
written to the stream being [flushed/closed].
I believe the intention of the statement is that implementations
should do the equivalent of lseek(fileno(fp), ftello(fp), SEEK_SET).
The point is to prevent data loss when changing the active handle for
an open file description to a handle in a different process. Thus if
app1 uses stdio to read from stdin,
{ app1; app2; } < file
works as expected without app1 having to do anything special. It just
reads from stdin and then closes it (explicitly or implicitly).
However, the wording used does not match this intent when ungetc() is
involved.
Suppose app1 is the type of application that performs read-ahead when
it parses its input, and the last thing it did is to call ungetc()
before closing standard input. In this case the lseek() above is
still the right thing for the implementation to do, so that app2 will
read the first byte that was "unwanted" by app1. However, that's not
what the statement in the standard requires. The last byte read by app1
was the byte that it passed to ungetc(). The ungetc() doesn't change
history; it changes what is returned by the next read on the stream
(if any).
To match the intent, the wording should be changed so that it simply
says the file offset of the underlying open file description is set to
the file position of the stream.
Another issue is what happens after an ungetc() and fflush() if the
active file handle does not change, i.e. there is a subsequent read
from the same stream. Should fflush() discard the pushed-back byte
or not? Given that the file offset of the underlying open file
description has (for the reasons above) been set to the file position
of the stream, I think fflush() does have to discard the pushed-back
byte. Otherwise that byte will be read twice after the fflush().
Desired Action:
Change:
the file offset of the underlying open file description shall be
adjusted so that the next operation on the open file description
deals with the byte after the last one read from or written to the
stream being flushed.
to:
the file offset of the underlying open file description shall be
set to the file position of the stream, and any characters pushed
back onto the stream by ungetc() or ungetwc() that have not
subsequently been read from the stream shall be discarded.
At page 805 line 26801 section fclose, change:
the file offset of the underlying open file description shall be
adjusted so that the next operation on the open file description
deals with the byte after the last one read from or written to the
stream being closed.
to:
the file offset of the underlying open file description shall be
set to the file position of the stream.
======================================================================
|