This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC 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]

Re: why using wchar_t?


Alf Salte <salte@socketip.no> writes:

> I am not sure if this is a bug or if this is the way it's supposed to be
> but GCC does behave in a way that I for one did not expect it to behavee
> with regard to the handling of wchar_t data type.
> 
> On my machine (an IBM PC running Linux) whcar_t is defined to be a 4
> byte size (32 bits) data type so it can theoretically hold any UCS-4
> character including the full set of all Unicode characters in the range
> 0..0x10ffff. However, when defining a wide character string holding
> non-ASCII characters, this is not taken advantage of. For example a
> declaration as the one below in a source file:
> 
>         const wchar_t str[] = L"Lørdag";
> 
> The problematic character here is the letter LATIN SMALL LETTER O WITH
> STROKE encoded as U+00f8 in unicode is stored int he string using TWO
> wchar_t characters containing the UTF-8 translation of the character,
> i.e. the string is equivalent to the following declaratation:
> 
> const wchar_t str[] = { L'L', wchar_t(0xc3), wchar_t(0xb8), L'r',
>         L'd', L'a', L'g', L'\0' };

Is it possible that:

1. You didn't compile GCC with --enable-c-mbchar (in which case it
   doesn't try to interpret bytes with the high bit set at all, it
   just passes them through); or

2. You didn't set your environment variables (especially LANG)
   appropriately to support UTF-8 encoded input?

-- 
- Geoffrey Keating <geoffk@geoffk.org>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]