This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
signature.asc
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |