[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190116202000.GJ23599@brightrain.aerifal.cx>
Date: Wed, 16 Jan 2019 15:20:00 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Minor C99 conformance issue: FILE is an incomplete type
On Wed, Jan 16, 2019 at 08:57:15PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2019-01-16 14:33:02 -0500]:
> > On Wed, Jan 16, 2019 at 01:25:57PM -0600, A. Wilcox wrote:
> > > On 01/16/19 13:06, Keith Thompson wrote:
> > > > The musl 1.0.0 manual says that it's intended to conform to C99.
> > > >
> > > > Both the C99 and C11 standards require FILE to be an object type.
> > > >
> > > > In C99, incomplete types are not object types. In C11, the definition
> > > > of "object type" was changed, so now incomplete types are object types.
> > > > (See section C99 and C11 6.2.5, C99 7.19.1, C11 7.21.1.)
> > > >
> > > > So, in C99 FILE is not permitted to be an incomplete type, but in C11
> > > > it is. (The section describing type FILE did not change. I don't
> > > > know whether the authors of the standard actually intended to change
> > > > the requirement.)
> > > >
> > > > Using musl-gcc, FILE is an incomplete type, so it conforms to C11
> > > > but not to C99. <stdio.h> could be modified so that, for example,
> > > > it pays attention to the value of __STDC_VERSION__ to decide how to
> > > > define FILE (whether to make struct _IO_FILE visible).
> >
> > The real struct _IO_FILE cannot be made visible because its size and
> > representation are not public or preserved across versions. A fake one
> > could be; the reason it hasn't been is that it requires extra work to
> > suppress the fake definition inside libc. But it could be done,
> > especially now with the internal wrapper headers (commit
> > 13d1afa46f8098df290008c681816c9eb89ffbdb and related work).
>
> i assume the only point of a fake FILE is to satisfy some
> conformance test that uses sizeof(FILE) and not useful in
> any other way.. which means it's not really relevant in
> practice.
I don't see any other purpose. You can't even portably make sentinel
FILE objects with address guaranteed to compare not-equal to any
actual open FILE, since FILE* need not actually be a valid pointer to
anything (it could be some sort of opaque handle representable in a
pointer type).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
