Mail Archives: cygwin/2011/02/02/19:13:12
Hi Eric,
> I was asking:
>
> should wwchar_t (or xwchar_t, but not xchar_t) be 2-bytes on cygwin, but
> unlike the POSIX definition of wchar_t being always 1 character per
> unit, the new type is explicitly documented as being multi-unit on some
> platforms but with sane semantics
>
> or should it always be 4-bytes, where conversion from wchar_t to
> wwchar_t requires some efforts, and where the new type must be used
> everywhere (which means wrapping a lot of APIs), but where you can once
> again assume POSIX semantics of 1 character per unit, simplifying life
> of callers at the expense of converting to the new type
In the first case we wouldn't need a new type.
The plan is the second alternative. The goal is *not* to have to extend
each of quotearg.c, regcomp.c, mbchar.h, wc.c, etc. to handle UTF-16
explicitly with #ifdefs, more variables, and more logic.
> if it works out, should we also add wwchar_t natively into cygwin?
More and more Unix platforms offer only UTF-8 locales. One can predict
that in 10 years, all Unix platforms will offer only UTF-8 locales. At this
point wchar_t will be UCS-4 on all these platforms (except AIX).
The mbrtoc32 function from the C1X API that you pointed to will then be
equivalent to mbrtowwc.
So, you can view 'wwchar_t' as a temporary measure that will bridge the
gap between the ANSI C Amd. 1 API and the C1X API.
Bruno
--
In memoriam Carl Friedrich Goerdeler <http://en.wikipedia.org/wiki/Carl_Friedrich_Goerdeler>
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -