[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190116193302.GI23599@brightrain.aerifal.cx>
Date: Wed, 16 Jan 2019 14:33:02 -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 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 do not suggest that this minor non-conformance to C99 is a practical
> > problem, or even that it should be fixed, merely that it should
> > be noted.
>
> This was noted by our POSIX conformance testing. There was a discussion
> in the #musl IRC about possibly making a fake _IO_FILE to satisfy not
> just POSIX but some miscreant glibc apps. However, I believe it was
> decided not to do that.
I'm not opposed to it, but it also hasn't seemed like a priority to
work on, and catching programs that are wrongly (from a
future-proofness standpoint, and from a semantic nonsense standpoint)
depending on it seems to have been helpful in getting them fixed.
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.
