Re: 16-bit wchar_t on Windows and Cygwin

[Bruno Haible <bruno at clisp dot org>]

Hello Eric,

> > 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.
> ...
> 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.

  - 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.

> 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.

If a developer makes a typo here, he's likely to get a gcc warning or
a link error. But yes, it's possible to pass a 'wwchar_t' to
iswalpha(), which will yield wrong results. I don't think this risk
can be much reduced through a different name.

> 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'

Good point. The 'x' prefix has already several meanings in gnulib:
  - checking against memory allocation failure,
  - checking against errors,
  - no size limitation,
  - a more convenient interface,
  - a wrapper that prints an error message.
It doesn't seem wise to add another meaning to it.

Thanks for the feedback.

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