Issue 1033: FILE as a void type

Authors: Jay Ghiron
Date: 2026-03-17
Submitted against: C23
Status: Review

No wording exists currently to say that FILE cannot be void or _Atomic void:

The types declared are

...

FILE

which is an object type capable of recording all the information needed to control a stream, including its file position indicator, a pointer to its associated buffer (if any), an error indicator that records whether a read/write error has occurred, and an end-of-file indicator that records whether the end of the file has been reached;

(C23 7.23.1 "Introduction" paragraph 3.)

In C11 the definition of object type was modified to include incomplete types, and this was intentionally extended to FILE so it can be defined as an incomplete type. For example:

typedef struct _FILE FILE;

Which will prevent programs from accessing the contents of a FILE through a FILE*. This change however also included allowing FILE to be defined as void or _Atomic void, though such definitions were likely not intended to be valid. A motivating example to forbid such definitions is so that _Generic can always distinguish between void* and FILE*. A definition of FILE as void would also result in lots of undesirable implicit conversions to FILE* being possible.

Suggested correction

Modify C23 7.23.1 paragraph 3:

FILE

which is an object type other than a void type capable of recording all the information needed to control a stream, including its file position indicator, a pointer to its associated buffer (if any), an error indicator that records whether a read/write error has occurred, and an end-of-file indicator that records whether the end of the file has been reached;

Note: The wording "a void type" is already used to include _Atomic void, though that is never clearly defined.

Comment from Issues list maintainer on 2026-08-21:

This issue was discussed at the August 2026 (Ottawa) meeting of WG14. It was suggested that if such a restriction were added, it should be to require FILE to be a structure or union type, rather than only excluding void types; it would also be necessary to investigate the effect of such a restriction on existing implementations. The committee agreed that no such restriction on the type of FILE was needed, subject to review at the next meeting.

Proposed response

It is OK for FILE to be a void type.