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
