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) ..."