public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/15551] New: GCC's -fshort-wchar support
@ 2013-05-30 14:28 yann at droneaud dot fr
2013-05-30 14:35 ` [Bug libc/15551] " yann at droneaud dot fr
2014-06-13 17:35 ` fweimer at redhat dot com
0 siblings, 2 replies; 3+ messages in thread
From: yann at droneaud dot fr @ 2013-05-30 14:28 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug libc/15551] GCC's -fshort-wchar support
2013-05-30 14:28 [Bug libc/15551] New: GCC's -fshort-wchar support yann at droneaud dot fr
@ 2013-05-30 14:35 ` yann at droneaud dot fr
2014-06-13 17:35 ` fweimer at redhat dot com
1 sibling, 0 replies; 3+ messages in thread
From: yann at droneaud dot fr @ 2013-05-30 14:35 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15551
Yann Droneaud <yann at droneaud dot fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Version|unspecified |2.15
Resolution|--- |DUPLICATE
--- Comment #1 from Yann Droneaud <yann at droneaud dot fr> ---
This bug seems to be fixed in git, but it's not yet part of the release.
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=052aff95782fefe9c63566471063e8b20836bfb8
http://sourceware.org/git/?p=glibc.git;a=blob;f=bits/wchar.h;hb=HEAD
This a likely a duplicate of bug #15036, I'm closing this bug.
Regards.
*** This bug has been marked as a duplicate of bug 15036 ***
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug libc/15551] GCC's -fshort-wchar support
2013-05-30 14:28 [Bug libc/15551] New: GCC's -fshort-wchar support yann at droneaud dot fr
2013-05-30 14:35 ` [Bug libc/15551] " yann at droneaud dot fr
@ 2014-06-13 17:35 ` fweimer at redhat dot com
1 sibling, 0 replies; 3+ messages in thread
From: fweimer at redhat dot com @ 2014-06-13 17:35 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=15551
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |security-
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-06-13 17:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-30 14:28 [Bug libc/15551] New: GCC's -fshort-wchar support yann at droneaud dot fr
2013-05-30 14:35 ` [Bug libc/15551] " yann at droneaud dot fr
2014-06-13 17:35 ` fweimer at redhat dot com
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).