Re: duplicate FILE typedef, stdio.h and wchar.h

[Corinna Vinschen <vinschen at redhat dot com>]

Hi Craig,

On Mar  3 23:05, Craig Howland wrote:
>      stdio.h and wchar.h both have unconditional "typedef FILE __FILE"
> declarations, which causes GCC to error out if both are included to the same
> source, which happens in any number of newlib source files.  (For example,
> libc/stdlib/btowc.c.)

I'm rather puzzled by this observation.  As you may imagine, these files
are used for a long time in packages in the Cygwin distro, and if GCC
would error out in this simple case, we had a lot of complaints from
Cygwin package maintainers.  So the first question is, in which scenario
do you see this problem?  I created an STC:

--8<---------------cut here---------------start------------->8---
#include <wchar.h>
#include <stdio.h>

extern FILE *foo (FILE *);

int main ()
{
  FILE *fp = foo (NULL);
  if (fp)
    foo (fp);
  return 0;
}
--8<---------------cut here---------------end--------------->8---

and gcc -c -g -O2 -Wall does not error out, nor does it even produce
a warning.  Same when reordering the includes.  Not even with -ansi.

>      The issue apparently was introduced with wchar.h version 1.34 on 23
> Dec 2013, when that typedef was added.  (How I managed to not run into this
> error until now is a surprise.)
>      The C99 standard does not specify FILE being defined in wchar.h, while
> POSIX has it listed as an extension to C.  Both C and POSIX give synopses
> for wide-character functions which have FILE in the prototype as:
> 
> #include <stdio.h>
> #include <wchar.h>
> [function]
> 
> This implicitly says that FILE should not be defined in wchar.h to avoid
> duplication.  And if it were to be put in per the POSIX CX, it would
> essentially always get protected out.

The POSIX CX explicitely defines that it's an extension with the
property that "Application developers may make use of an extension as it
is supported on all POSIX.1-2008-conforming systems."  I'd say that's
a good reason to define FILE in wchar.h.  The POSIX standard is not
free from bugs, of course...

> (Makes you wonder why POSIX added
> it.  GCC certainly does not need it, as evidenced by wchar.h being fine
> prior to Dec 2013 (all FILEs in wchar.h are FILE *).)
>      Despite POSIX and C, Newlib source sometimes includes wchar.h first,
> partly because sometimes the inclusions of one or the other of the file are
> indirect.
>      The question is, what is the right way to address the problem? Should
> it have the proper POSIX CX protection macro put on it?  (But that, in itself
> would not fix the Newlib build issues that I'm seeing, since CX is often
> activated, I suspect.)  Revert the addition to wchar.h?  (We got along fine
> before that, but then that bit of POSIX would be lacking, even if its
> desirability is questionable.)  Add duplication-protection macros to both
> files, to allow both orders?  (It would work, but is probably really not
> proper according to the C standard.)
>      While I don't like it much, I've attached a patch for the latter
> solution under the assumption that it might be the preferred choice.
>      (By the way, looking at GLIBC was of no help, as they do it in a bad
> way, including stdio.h in wchar.h--which is expressly forbidden by the
> standards.)

I like it.  Please apply.  Alternatively we'd split out shared
definitions like this into extra files under some directory like "bits",
as glibc does, but it seems a lot of error-prone reshuffling effort.


Thanks,
Corinna


-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: pgp43COa6vxtc.pgp
Description: PGP signature