Bug 15551 - GCC's -fshort-wchar support
Summary: GCC's -fshort-wchar support
Status: RESOLVED DUPLICATE of bug 15036
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.15
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-30 14:28 UTC by Yann Droneaud
Modified: 2014-06-13 17:35 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
Little test case (312 bytes, text/x-csrc)
2013-05-30 14:28 UTC, Yann Droneaud
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yann Droneaud 2013-05-30 14:28:20 UTC
Created attachment 7050 [details]
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.
Comment 1 Yann Droneaud 2013-05-30 14:35:09 UTC
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 ***