[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 16-bit wchar_t on Windows and Cygwin
From: |
Corinna Vinschen |
Subject: |
Re: 16-bit wchar_t on Windows and Cygwin |
Date: |
Wed, 2 Feb 2011 22:38:42 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Feb 2 14:24, Eric Blake wrote:
> [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.
May I suggest a compromise? What about "xwchar_t"? It avoids the
potential typo by accidentally dropping the second w. It still contains
"wchar" which implies that it's a *wide* char type. And the x could be
read as "extended".
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
- Re: bug#7948: 16-bit wchar_t on Windows and Cygwin, (continued)
Re: 16-bit wchar_t on Windows and Cygwin,
Corinna Vinschen <=