Austin Group Defect Tracker

Aardvark Mark IV


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
Reporter EdSchouten View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Ed Schouten
Organization Nuxi
User Reference
Section stdio.h
Page Number n/a
Line Number n/a
Interp Status ---
Final Accepted Text See Note: 0003807.
Summary 0001054: stdio.h doesn't allow FILE to be opaque?
Description FILE is described by <stdio.h> as follows:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdio.h.html [^]

FILE
A structure containing information about a file.

Looking at <dirent.h>, we see that DIR is described differently:

DIR
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.
Desired Action Change the description of FILE from:

A structure containing information about a file.

to:

A type containing information about a file. The FILE type may be an incomplete type.
Tags issue8
Attached Files

- Relationships

-  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


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