This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: why using wchar_t?
- From: Geoff Keating <geoffk at geoffk dot org>
- To: Alf Salte <salte at socketip dot no>
- Cc: gcc-bugs at gcc dot gnu dot org
- Date: 24 Oct 2002 08:40:27 -0700
- Subject: Re: why using wchar_t?
- References: <1035469840.26170.54.camel@socketip111>
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>