public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "yann at droneaud dot fr" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/15551] New: GCC's -fshort-wchar support Date: Thu, 30 May 2013 14:28:00 -0000 [thread overview] Message-ID: <bug-15551-131@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=15551 Bug ID: 15551 Summary: GCC's -fshort-wchar support Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: libc Assignee: unassigned at sourceware dot org Reporter: yann at droneaud dot fr CC: drepper.fsp at gmail dot com Created attachment 7050 --> http://sourceware.org/bugzilla/attachment.cgi?id=7050&action=edit Little test case Hi, I'm using Fedora 17, with GLIBC 2.15 and GCC 4.7.2 20120921 (Red Hat 4.7.2-2). I have a little problem regarding GLIBC interaction with GCC -fshort-wchar. http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Code-Gen-Options.html#index-fshort_002dwchar-2338 wchar_t type is defined by <stddef.h> which is provided by GCC but WCHAR_MIN and WCHAR_MAX are defined in <stdint.h>, provided by GLIBC. I'm aware that GLIBC functions cannot be used within a program built with -fshort-wchar ... such kind of ABI change cannot be supported (and who want it ?). http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32240#c2 I guess it will be caught at linker time, but I haven't tried yet: I don't want and I don't need the wchar related functions provided by the GLIBC. I just "want" to building a "legacy" application that think a wchar_t is 2 bytes long. In order to build this part of the application, someone suggest to use GCC's option -fshort-wchar, which change the way wchar_t is defined: - without -fshort-wchar: # 325 "/usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/stddef.h" 3 4 typedef int wchar_t; - with -fshort-wchar: # 325 "/usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/stddef.h" 3 4 typedef short unsigned int wchar_t; That's easy at it's sound. But, the macro for reporting the minimum and maximum value are not affected: const size_t swmin = (-2147483647 - 1); const size_t swmax = (2147483647); So here, GLIBC is defining it's own values for WCHAR_MIN and WCHAR_MAX within /usr/include/bits/wchar.h #define __WCHAR_MIN (-2147483647 - 1) #define __WCHAR_MAX (2147483647) Preprocessing an empty file shows that GCC has some predefined macro to help defining WCHAR_MIN and WCHAR_MAX $ gcc -W -Wall -Wp,-dM -E null.c | grep -i wchar #define __WCHAR_MAX__ 2147483647 #define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1) #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2 #define __WCHAR_TYPE__ int #define __SIZEOF_WCHAR_T__ 4 $ gcc -W -Wall -fshort-wchar -Wp,-dM -E null.c | grep -i wchar #define __WCHAR_MAX__ 65535 #define __WCHAR_MIN__ 0 #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2 #define __WCHAR_TYPE__ short unsigned int #define __SIZEOF_WCHAR_T__ 2 My application rely on the correct definition of WCHAR_MIN and WCHAR_MAX. So I think that, even if GLIBC is never going to support -fshort-wchar, WCHAR_MIN and WCHAR_MAX must be correct. The value must be given by the compiler. [Note: Those macros can be used to disable prototypes for wchar functions, if the size of wchar_t is not the one of the GLIBC ABI] Regards. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2013-05-30 14:28 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-05-30 14:28 yann at droneaud dot fr [this message] 2013-05-30 14:35 ` [Bug libc/15551] " yann at droneaud dot fr 2014-06-13 17:35 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-15551-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).