0001054: stdio.h doesn't allow FILE to be opaque?

Notes
(0003238) geoffclare (manager) 2016-05-31 10:08	I gather than this issue has previously been discussed by the C committee and they made a change in C11 which allows FILE to be incomplete. We should make a suitable change in Issue 8 to match C11 (probably by adopting the C11 wording instead of our current wording). We cannot allow incomplete FILE in TC3 (if we do a TC3), as it would introduce a conflict with C99.

(0003239) shware_systems (reporter) 2016-05-31 15:25 edited on: 2016-05-31 15:54	I thought POSIX had FILE as a complete structure type to allow it to be the header of additional structures, like DIR, that might be incomplete and since only the types of items it is expected to hold is described, not actual field name assignments, is opaque. I see no compelling reason Issue 8 should change that deferral. At most it gets marked CX as a subset of what c11 says is allowed non-POSIX implementations of the library, with explanation for the shading added to Rationale. It looks more like c11 tried to fold DIR into FILE, by copying how DIR is worded, expecting POSIX might want to change all references to DIR's to FILE's; rather than make a similar allowance that <stdio.h> may have incomplete types that use a field of type FILE declared by an implementation. ------ Sorry, c99 allows incomplete types also for FILE and c11 uses the same definition, just that it be an object type; it's fpos_t that got changed in c11, so scratch last paragraph. Adding CX shading still looks desirable, though.

(0003805) eblake (manager) 2017-06-29 15:39	The gnulib source-code library used in a lot of GNU (and other) software implements several useful extension functions on top of stdio. For example: http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/fpending.c [^] declares fpending(FILE fp), which lets an application probe whether a file has unflushed data. Applications using this extension (including various GNU coreutils) can then be written in a more efficient manner. Some libc already offer an __fpending(), which gnulib uses instead of poking into FILE internals; and it may be worth standardizing under the fpending() name (probably as a separate bug report from this one). The gnulib implementation is rather complicated _because_ it pokes at FILE internals, and has to deal with incomplete types on a per-libc basis for how to poke at those internals (there are regularly reports on the gnulib mailing list about yet-another libc that needs porting to provide all of the stdio extensions). So writing such extensions are already quite aware of the non-portability of probing at FILE internals, and making FILE opaque does not (greatly) change the situation. So I'm not opposed to this change; however, we probably want to make sure that we have enough building-blocks on top of stdio (even if it means standardizing some of the gnulib extensions and/or the __f() counterparts that various BSDs have added to help gnulib write such extensions without probing in FILE guts), so that applications can still access optimizations in a more portable manner.

(0003806) wlerch (reporter) 2017-06-29 17:53	Both C99 and C11 refer to FILE as an "object type" but the meaning of "object type" is different -- in C99 it does not include incomplete types and in C11 it does: C99 "Types are partitioned into object types (types that fully describe objects), function types (types that describe functions), and incomplete types (types that describe objects but lack information needed to determine their sizes)." C11 "Types are partitioned into object types (types that describe objects) and function types (types that describe functions). At various points within a translation unit an object type may be incomplete (lacking sufficient information to determine the size of objects of that type) or complete (having sufficient information)."

(0003807) Don Cragun (manager) 2017-07-06 15:30	Make the change suggested in the Desired Action and also add new paragraph in the <stdio.h> Application Usage section after P357, L12184: Since the latest revision of the C Standard allows FILE to be an incomplete type (and POSIX also allows it), portable applications can no longer allocate or copy an object of type FILE; only pointers to objects of type FILE can be allocated.

Issue History
Date Modified	Username	Field	Change
2016-05-31 09:45	EdSchouten	New Issue
2016-05-31 09:45	EdSchouten	Status	New => Under Review
2016-05-31 09:45	EdSchouten	Assigned To	=> ajosey
2016-05-31 09:45	EdSchouten	Name	=> Ed Schouten
2016-05-31 09:45	EdSchouten	Organization	=> Nuxi
2016-05-31 09:45	EdSchouten	Section	=> stdio.h
2016-05-31 09:45	EdSchouten	Page Number	=> n/a
2016-05-31 09:45	EdSchouten	Line Number	=> n/a
2016-05-31 10:08	geoffclare	Note Added: 0003238
2016-05-31 15:25	shware_systems	Note Added: 0003239
2016-05-31 15:40	shware_systems	Note Edited: 0003239
2016-05-31 15:54	shware_systems	Note Edited: 0003239
2017-06-29 15:39	eblake	Note Added: 0003805
2017-06-29 17:53	wlerch	Note Added: 0003806
2017-07-06 15:30	Don Cragun	Note Added: 0003807
2017-07-06 15:31	Don Cragun	Interp Status	=> ---
2017-07-06 15:31	Don Cragun	Final Accepted Text	=> See Note: 0003807.
2017-07-06 15:31	Don Cragun	Status	Under Review => Resolved
2017-07-06 15:31	Don Cragun	Resolution	Open => Accepted As Marked
2017-07-06 15:32	Don Cragun	Tag Attached: issue8
2020-04-16 08:57	geoffclare	Status	Resolved => Applied
2024-06-11 08:52	agadmin	Status	Applied => Closed

Relationships

Aardvark Mark IV