Austin Group Defect Tracker

Aardvark Mark III

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000087 [1003.1(2008)/Issue 7] System Interfaces Objection Error 2009-06-29 17:30 2009-10-12 05:32
Reporter geoffclare View Status public  
Assigned To ajosey
Priority normal Resolution Accepted  
Status Interpretation Required  
Name Geoff Clare
Organization
User Reference
Section fflush
Page Number 844
Line Number 28024
Interp Status Approved
Final Accepted Text Note: 0000181
Summary 0000087: 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.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0000181)
ajosey (manager)
2009-08-06 15:56
edited on: 2009-10-12 05:32

 Interpretation response
------------------------
The standard is unclear on this issue, and no conformance
distinction can be made between alternative implementations based
on this. This is being referred to the sponsor.

Rationale:
-------------
None.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

Make the change suggested by the submitter

- Issue History
Date Modified Username Field Change
2009-06-29 17:30 msbrown New Issue
2009-06-29 17:30 msbrown Status New => Under Review
2009-06-29 17:30 msbrown Assigned To => ajosey
2009-06-29 17:30 msbrown Name => Mark Brown
2009-06-29 17:30 msbrown Organization => IBM
2009-06-29 17:30 msbrown Section => fflush
2009-06-29 17:30 msbrown Page Number => 844
2009-06-29 17:30 msbrown Line Number => 28024
2009-06-29 17:30 msbrown Status Under Review => Resolved
2009-06-29 17:30 msbrown Resolution Open => Accepted
2009-07-01 17:05 msbrown Name Mark Brown => Geoff Clare
2009-07-01 17:05 msbrown Organization IBM =>
2009-07-01 17:05 msbrown Reporter msbrown => geoffclare
2009-08-06 15:56 ajosey Note Added: 0000181
2009-08-06 15:56 ajosey Status Resolved => Interpretation Required
2009-08-11 16:36 Don Cragun Interp Status => Pending
2009-09-17 15:41 nick Interp Status Pending => Proposed
2009-10-12 05:32 ajosey Note Edited: 0000181
2009-10-12 05:32 ajosey Interp Status Proposed => Approved
2009-10-12 05:32 ajosey Final Accepted Text => Note: 0000181

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker