From: Bruno Haible <bruno@clisp.org>
To: bug-gnulib@gnu.org
Cc: Eric Blake <eblake@redhat.com>, cygwin@cygwin.com
Subject: Re: 16-bit wchar_t on Windows and Cygwin
Date: Wed, 02 Feb 2011 23:03:00 -0000 [thread overview]
Message-ID: <201102030003.46763.bruno@clisp.org> (raw)
In-Reply-To: <4D49CB7C.5040000@redhat.com>
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
next prev parent reply other threads:[~2011-02-02 23:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201101310304.42975.bruno@clisp.org>
2011-01-31 19:16 ` Eric Blake
2011-01-31 20:49 ` Corinna Vinschen
2011-02-02 11:29 ` Bruno Haible
2011-02-02 12:15 ` Corinna Vinschen
2011-02-02 12:21 ` Corinna Vinschen
2011-02-02 16:03 ` Bruno Haible
2011-02-02 16:28 ` Corinna Vinschen
2011-02-02 16:35 ` Corinna Vinschen
2011-02-02 20:28 ` Andy Koppe
2011-02-04 22:46 ` Warren Young
2011-02-02 17:52 ` bug#7948: " Paul Eggert
2011-02-02 18:57 ` Bruno Haible
2011-02-02 20:43 ` Andy Koppe
2011-02-03 12:57 ` Ulf Zibis
2011-02-02 21:24 ` Eric Blake
2011-02-02 21:39 ` Corinna Vinschen
2011-02-02 23:03 ` Bruno Haible [this message]
2011-02-02 23:19 ` Eric Blake
2011-02-03 0:13 ` Bruno Haible
2011-02-03 9:42 ` Corinna Vinschen
2011-02-03 10:48 ` Bruno Haible
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201102030003.46763.bruno@clisp.org \
--to=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=cygwin@cygwin.com \
--cc=eblake@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).