duplicate FILE typedef, stdio.h and wchar.h

[Eric Blake]

On 03/03/2015 09:05 PM, 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.)
>      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.  (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 *).)

The C standard requires a strict C program to include both headers in
proper order.  The POSIX standard explicitly went one step further, and
requires that <wchar.h> be self-standing and that a person can use it
without including <stdio.h>.  This was an intentional design decision in
POSIX.

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

And according to POSIX rules (but not stricter C rules) this should work.

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

CX markings in POSIX mean something that POSIX requires of the
implementation above and beyond what C requires.  There is no way to
disable CX extensions when compiling for a POSIX environment; the only
way to compile for an environment where CX is not present is to ditch
POSIX and compile for strictly ANSI C compliance.  And we already know
that newlib is not (yet) very good at avoiding namespace pollution for
someone attempting to compile to just ANSI C compliance, because in
practice so few people are trying to use such a spartan environment.

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

Or factor out the FILE typedef into a separate internal header that both
<stdio.h> and <wchar.h> include, so that both public headers are
properly self-contained with regards to FILE all without having to
include one another.

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

No, the standards (at least, the POSIX standard) do NOT forbid wchar.h
from including stdio.h:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/wchar.h.html#tag_13_83

"[CX] [Option Start] Inclusion of the <wchar.h> header may make visible
all symbols from the headers <ctype.h>, <string.h>, <stdarg.h>,
<stddef.h>, <stdio.h>, <stdlib.h>, and <time.h>. [Option End]"

which means, when compiling for POSIX, the namespace pollution is
perfectly acceptable, although not required.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/newlib/attachments/20150304/8d9548ac/attachment.sig>