[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ucs4_t type
From: |
Bruno Haible |
Subject: |
Re: ucs4_t type |
Date: |
Wed, 28 Jul 2010 23:50:24 +0200 |
User-agent: |
KMail/1.9.9 |
Paolo Bonzini wrote:
> BTW, there's an interesting difference between char32_t and ucs4_t, in
> that the former has "the same size, signedness, and alignment as
> uint_least32_t", while libunistring uses uint32_t to define the latter.
This is because libunistring (and gnulib) simply assume that uint32_t
exists. We don't attempt portability to platforms with 36-bit register
words.
> I wonder if libunistring should be changed to:
>
> 1) detect _Char32_t (or uchar.h and char32_t) and use it if available,
You would have to be careful when doing this:
* This definition could only be done when char32_t exists as a type
and if __STDC_UTF_32__ is defined to 1. But this depends on the
compiler brand and version. Shared libraries must have an ABI that
is independent of the compiler.
* Also, compilers could define char16_t to be uint32_t, or char32_t to
be uint64_t, which would be a binary incompatible change.
Basically, I don't think many applications will use char16_t and char32_t
in portable programs on Unix, because these types are useless when
__STDC_UTF_32__ is not defined. The C1X [1] standard designers are repeating
the same mistake they did with wchar_t. The reason wchar_t did not take
off on Unix is that its encoding is platform dependent. The proposed C1X
standard specifies the same thing for char16_t and char32_t ([2] p. 560).
Bruno
[1] http://en.wikipedia.org/wiki/C1X
[2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1494.pdf
- [PATCH v2 2/5] unistr/u*-chr: test multibyte sequences, (continued)
- [PATCH v2 2/5] unistr/u*-chr: test multibyte sequences, bonzini, 2010/07/23
- [PATCH v2 3/5] unistr/u*-chr: test multibyte sequences more, bonzini, 2010/07/23
- [PATCH v2 4/5] unistr/u*-strchr: add tests, bonzini, 2010/07/23
- [PATCH v2 5/5] unistr/u8-chr, unistr/u8-strchr: use Boyer-Moore like algorithm., bonzini, 2010/07/23
- Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm, Bruno Haible, 2010/07/23
- Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm, Bruno Haible, 2010/07/28
- Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm, Pádraig Brady, 2010/07/29
- Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm, Paolo Bonzini, 2010/07/29
- Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm, Pádraig Brady, 2010/07/29
- Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm, Paolo Bonzini, 2010/07/29
- Message not available
- Message not available
- Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm, Paolo Bonzini, 2010/07/29
- Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm, Bruno Haible, 2010/07/29
- Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm, Paolo Bonzini, 2010/07/29
- Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm, Bruno Haible, 2010/07/31
- guarantees of u8_mbtouc/u8_strmbtouc (was Re: [PATCH v2 0/5] Speed up uNN_chr and uNN_strchr with Boyer-Moore algorithm), Paolo Bonzini, 2010/07/29