Re: 16-bit wchar_t on Windows and Cygwin

[Eric Blake]

[dropping coreutils at this point]

On 02/02/2011 04:29 AM, Bruno Haible wrote:
> Good point. I agree then that overriding wchar_t should better not be
> done.
> 
> Here's a new proposal:
>   - Define a type 'wwchar_t' on all platforms, equivalent to uint32_t
>     on Windows platforms and to 'wchar_t' otherwise.
>   - Define functions 'mbrtowwc', 'iswwalpha', 'wwcwidth', and similar.
>     Their definition will be a trivial redirection to 'mbrtowc', 'iswalpha',
>     'wcwidth' on most platforms, and a use of libunistring modules on
>     Windows platforms.

I like the idea of making a new type wrapper.

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)?

As to the name: I agree the opinion of others that xchar_t is easier to
type and easier to avoid typos of a missing 'w' than wwchar_t.  On the
other hand, I can see wwprintf that takes wide-wchar_t values, but
gnulib already has xprintf as a counterpart to xmalloc (which calls
exit() if the printf fails for memory allocation or other non-I/O
related reasons), so we can't blindly use 'x' instead of 'ww' when
replacing existing 'w' in POSIX APIs.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature