[tex-k] Fwd: [icu-support] ICU4C UChar & U_STRING_DECL subtle changes

[Jonathan Kew]

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.

JK

-------- 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
the same.

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
<http://www.icu-project.org/apiref/icu4c/ustring_8h.html#adf24e553d2f30e3bde48ff98d9b0e6bc> 

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
UChar!=char16_t.)

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
an array.

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.

Best regards,
markus
-- 
Google Internationalization Engineering