Minor C99 conformance issue: FILE is an incomplete type

Minor C99 conformance issue: FILE is an incomplete type

[Keith Thompson]

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).

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.

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.1 LTS"

$ uname -a
Linux bomb20 4.15.0-42-generic #45-Ubuntu SMP Thu Nov 15 19:32:57 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux

$ dpkg -l musl
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                      Version
 Architecture              Description
+++-=========================================-=========================-=========================-=======================================================================================
ii  musl:amd64                                1.1.19-1
 amd64                     standard C library

$ gcc --version
gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat FILE_bug.c.
#include <stdio.h>
int main(void) {
    printf("sizeof (FILE) = %zu\n", sizeof (FILE));
}

$ musl-gcc -std=c99 -c FILE_bug.c
FILE_bug.c: In function ‘main’:
FILE_bug.c:3:45: error: invalid application of ‘sizeof’ to
incomplete type ‘FILE {aka struct _IO_FILE}’
     printf("sizeof (FILE) = %zu\n", sizeof (FILE));
                                             ^~~~
$ musl-gcc -std=c11 -c FILE_bug.c
FILE_bug.c: In function ‘main’:
FILE_bug.c:3:45: error: invalid application of ‘sizeof’ to
incomplete type ‘FILE {aka struct _IO_FILE}’
     printf("sizeof (FILE) = %zu\n", sizeof (FILE));
                                             ^~~~

Re: Minor C99 conformance issue: FILE is an incomplete type

[A. Wilcox]

[-- Attachment #1.1: Type: text/plain, Size: 1414 bytes --]

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).
> 
> 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.

Best,
--arw

-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Minor C99 conformance issue: FILE is an incomplete type

[Rich Felker]

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

Re: Minor C99 conformance issue: FILE is an incomplete type

[A. Wilcox]

[-- Attachment #1.1: Type: text/plain, Size: 1037 bytes --]

On 01/16/19 13:33, Rich Felker wrote:
> On Wed, Jan 16, 2019 at 01:25:57PM -0600, A. Wilcox wrote:
>> 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
> 


Perhaps this could only be enabled when __STDC_VERSION__ == 199901L
(iirc?) *and* __STRICT_ANSI__ are defined, and no other FTM (_BSD, _GNU,
etc).  I'm unaware of *any* software that uses -std=c99 -ansi without
other FTM (though I have seen one -std=c89 -ansi with no other FTM).

Best,
--arw

-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Minor C99 conformance issue: FILE is an incomplete type

[Szabolcs Nagy]

* Rich Felker <dalias@libc.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 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

Re: Minor C99 conformance issue: FILE is an incomplete type

[Rich Felker]

On Wed, Jan 16, 2019 at 08:57:15PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.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