Why not use (one or more) string(!) datatype(s) named UTF_8, UTF_16,
UTF_32 (or UCS_4, if you prefer that name) each tied to one of the
encodings of 10646? That would make it clear what kind of datatype
it is, and the wchar_t ambiguity is gone.
This does NOT mean that I *in any way whatsoever* support the draft
15431. It would be fair to know that previous drafts have been
very stongly criticised on several points.
Kind regards
/kent k
> -----Original Message-----
> From: Bruno Haible [mailto:haible@xxxxxxx]
> Sent: Friday, February 04, 2000 2:45 PM
> To: linux-utf8@xxxxxxxxxxxx
> Subject: Re: Anybody working on ISO/IEC 15435 (i18n.h)?
>
>
> Kai Henningsen writes:
>
> > Which reminds me I probably want to have some internal type
> in place of
> > wchar_t, in case someone wants to port to a compiler where
> wchar_t isn't
> > large enough to hold 31 bits. (I remember seeing
> sizeof(wchar_t)==2 once.)
>
> On some systems you even have sizeof(wchar_t)==1. The people
> who designed
> this decided that they didn't want internationalized programs on their
> platform. Too bad for them.