[tex-k] Fwd: [icu-support] ICU4C UChar & U_STRING_DECL subtle changes
jfkthame at googlemail.com
Fri Nov 9 23:25:46 CET 2012
Hi Norbert et al,
I think this change (just checked-in to ICU) will probably resolve the
build problems you've been seeing, if you can't work around the problem
by some adjustment to configure/compiler options.
-------- Original Message --------
Subject: [icu-support] ICU4C UChar & U_STRING_DECL subtle changes
Date: Fri, 9 Nov 2012 14:16:17 -0800
From: Markus Scherer <markus.icu at gmail.com>
Reply-To: ICU support mailing list <icu-support at lists.sourceforge.net>
To: icu-design <icu-design at lists.sourceforge.net>, ICU support mailing
list <icu-support at lists.sourceforge.net>
Dear ICU users,
In ICU 50, we have attempted to define UChar=char16_t when possible,
similar to how we otherwise use wchar_t or else uint16_t.
However, this has broken several users' builds because in C++ the
char16_t is distinct from uint16_t/wchar_t even if it otherwise behaves
I have checked in a fix under ticket #9728
<http://bugs.icu-project.org/trac/ticket/9728> which changes back to not
automatically defining UChar=char16_t. It adds the ability to optionally
define a custom UCHAR_TYPE.
As a side effect, because u"abc" string literals have type char16_t* but
it can be UChar!=char16_ I had to change the U_STRING_DECL macro
so that it does not always declare an array any more; in some cases it
now declares a pointer variable, which allows a pointer type cast. (We
cannot initialize a UChar _/array/_ with a char16_t string literal when
If you have code that relies on the U_STRING_DECL macro defining an
array variable, then it might break, depending on the platform. You
would need to change your code so that it works with either a pointer or
We believe that this is very rare. In ICU, there was only
the U_STRING_DECL unit test itself that relied on the array variable.
Please let us know if this causes major problems.
Google Internationalization Engineering
More information about the tex-k