From: Eric Blake <eblake@redhat.com>
To: cygwin@cygwin.com, bug-gnulib <bug-gnulib@gnu.org>
Subject: Re: 16-bit wchar_t on Windows and Cygwin
Date: Wed, 02 Feb 2011 21:24:00 -0000 [thread overview]
Message-ID: <4D49CB7C.5040000@redhat.com> (raw)
In-Reply-To: <201102021229.04623.bruno@clisp.org>
[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]
[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 eblake@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]
next prev parent reply other threads:[~2011-02-02 21:24 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 [this message]
2011-02-02 21:39 ` Corinna Vinschen
2011-02-02 23:03 ` Bruno Haible
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=4D49CB7C.5040000@redhat.com \
--to=eblake@redhat.com \
--cc=bug-gnulib@gnu.org \
--cc=cygwin@cygwin.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).