On Apr 19, 2010, at 1:19 AM, Duncan Gibson wrote:

> Ian:
>> I was going to say that the wchar_t thing was likely to give us
>> problems on win32, but I see Albrecht already got there.
> 
> Yes, I didn't know whether to go for the typedef, or the #define.
> As the scope of the latter is usually cited as one of the big
> deficiencies of C/C++, I thought the typedef would be better.
> It would appear not.
> 
>> I have to say that, since are editing mk_wcwidth.c anyway, we should
>> probably just replace all the wchar_t with uint32_t and be done with
>> it, so that we don't ever have to worry about what size the system
>> thinks a wchar is.
> 
> Well I was hoping to be able to keep MK's code as vanilla as possible.
> If we do need to change it, and it now looks like we do, we should
> still make as few changes we can. I shall investigate this evening.
> 
>> It's clear from his code that MK was assuming that a wchar was going
>> to be 32-bits anyway, and that the code points would be set
>> accordingly - i.e directly to the Unicode value, not encoded as
>> utf-16 or utf-8 or anything.
> 
> I work with Lunar Linux, and I saw an update to the icu4c libraries
> go by last week (see http://icu-project.org) and was reading up about
> it over the weekend. Two things stood out that are relevant to UTF-8
> code in FLTK:
> 
> 1. I had assumed that wchar_t was fixed, or what is the point of it,
>   but then wchar_t is more of a C/POSIX thing than general Unicode:
>   see http://userguide.icu-project.org/posix
>   and http://icu-project.org/docs/papers/unicode_wchar_t.html
> 
> 2. Although UTF-8 encoding allows for up to 32 bits per character by
>   using a 6-byte encoding, both the Unicode Consortium and ISO have
>   decided that they don't need that full range any more. IIRC they
>   only need 21 bits to represent all characters. So this is probably
>   the reason for the statement somewhere in the FLTK code that it
>   only handles 24 bits.
> 
>   [It also says that only 16 bits are really needed for Linux and
>   Windows, which fits with a limited 16-bit wchar_t implementation]


Windows uses UTF-16 and *does* use/support code points beyond 0xffff.

________________________________________
Michael Sweet, Easy Software Products



_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to