|Anonymous | Login||2023-03-31 00:57 UTC|
|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|
|0001054||[1003.1(2008)/Issue 7] Base Definitions and Headers||Editorial||Omission||2016-05-31 09:45||2020-04-16 08:57|
|Priority||normal||Resolution||Accepted As Marked|
|Final Accepted Text||See Note: 0003807.|
|Summary||0001054: stdio.h doesn't allow FILE to be opaque?|
FILE is described by <stdio.h> as follows:
A structure containing information about a file.
Looking at <dirent.h>, we see that DIR is described differently:
A type representing a directory stream. The DIR type may be an incomplete type.
This difference in phrasing makes me assume that FILE may not be an incomplete type. Though it is true that many C library implementations allow you to mess around with FILE's innards, I think this is generally considered bad practice. There is also some work underway on FreeBSD to change FILE to be opaque.
Change the description of FILE from:
A structure containing information about a file.
A type containing information about a file. The FILE type may be an incomplete type.
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.
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.
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:
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.
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)."
Don Cragun (manager)
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.
|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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|