On 02/02/2011 04:03 PM, Bruno Haible wrote: >> Are you thinking of making a sane wrapping around either 4-byte wchar_t >> or which maps to 2-byte wchar_t but sanely handles UTF-16 (which makes >> it a thin wrapper on both Linux and Cygwin, but needing more work on >> mingw), or are you thinking that it is always a 4-byte type (needing >> lots more memory manipulation on cygwin to convert between 2- and 4-byte >> representations when using cygwin's functions, or else reimplementing >> everything from scratch by completely bypassing cygwin)? > > I'm not sure I understand your question. The plan is that > > - On platforms with a 32-bit wchar_t, like glibc, *BSD, and many others, > 'wwchar_t' is identical to 'wchar_t', and the function wrappers are > simple redirections. > > - On Cygwin and mingw, wwchar_t is 'uint32_t' (so as to accommodate > all Unicode characters and WEOF and so that it plays well with 'wint_t'). > mbrtowwc is implemented by 1 or 2 calls to mbrtowc. mbsrtowwcs may be > implemented by a call to mbsrtowcs and an additional conversion loop, > or it might be implemented on top of mbrtowwc; that's merely a speed > vs. memory trade-off. > The plan is not to "completely bypassing cygwin", but to use as much > of Cygwin's built-ins as makes sense. You answered my question in spite of myself. 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 And on asking the question in those more detailed words, I agree with your conclusion - on cygwin, wwchar_t should be 4 bytes. > > - On platforms with a 16-bit wchar_t but where the wchar_t[] encoding > in Unicode locales is merely UCS-2, like AIX, use the no-op thin > wrappers as well. If the platform does not support more than the BMP, > it makes not much sense for GNU programs to try to work around that. Agreed. Next question/thought. Gnulib should definitely tackle this first. But if it works out, should we also add wwchar_t natively into cygwin? It would certainly be easier to add new interfaces incrementally, in preparation for a possible future ABI conversion to make wchar_t become 4 bytes. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org