ISO/ IEC JTC1/SC22/WG14 N777

 Document Number: WG14 N777/J11 97-141
 C9X Revision Proposal
 =====================
 Title: File position indicator after fgetc failure
 Author: Fred J. Tydeman
 Author Affiliation: Tydeman Consulting
 Postal Address: 3711 Del Robles Dr., Austin, TX 78727-1814
 E-mail Address: tydeman@tybor.com
 Telephone Number: +1 (512) 255-8696
 Fax Number: +1 (512) 255-8696
 Sponsor: NCITS/J11
 Date: 1997年09月25日
 Document History: N/A.
 Proposal Category:
 __ Editorial change/non-normative contribution
 _Y Correction
 __ New feature
 __ Addition to obsolescent feature list
 __ Addition to Future Directions
 __ Other (please specify) ______________________________
 Area of Standard Affected:
 __ Environment
 __ Language
 __ Preprocessor
 _Y Library
 __ Macro/typedef/tag name
 _Y Function
 __ Header
 __ Other (please specify) ______________________________
 Prior Art: Not sure_________________________________________
 Target Audience: All users.
 Related Documents (if any): SC22WG14.2615__________________
 Proposal Attached: _Y Yes __ No, but what's your interest?
 Abstract: Have fgetc advance the file position indicator if
 and only if it obtains a character.
 Proposal:
 In 7.12.8.1 The fgetc Function and in 7.18.3.1 The fgetwc
 Function,
 change in the description:
 "... and advances the associated file position indicator for
 the stream (if defined)."
 to:
 "... and advances the associated file position indicator for
 the stream (if defined) if and only if the next [wide]
 character was present."
 Rationale:
 In previous email to the WG14 reflector, around June, 1996,
 several of us agreed that fgetc was unclear about the file
 position indicator if end-of-file or error indicator was set
 by fgetc and that a DR should be done. As far as I know,
 no one did that DR. This is my suggested fix to the problem.
 This fix appears to not conflict with footnote 165 in 7.12.3
 Files: "Setting the file position indicator to end-of-file,
 as with fseek(file,0,SEEK_END), has undefined behavior for a
 binary stream (because of possible trailing null characters)
 ..."