The test fails for "America/Argentina/ComodRivadavia", which has length
of 32, the same as the buffer. The results in the string being not
terminated with a NUL.
This increases the buffer size used by the test, and also checks for the
string not terminated warning.
- Updating API status version for ICU4J 65 release
- Fixed a few minor API doc issues in DecimalFormat and LocaleMatcher
- Update ICU4J API change report
This enables "classic" desktop builds of ICU4C for both ARM (32-bit)
and ARM64 (64-bit) on Windows.
All but the two samples "cal" and "date" in the "allinone" project now
have ARM and ARM64 project configurations, and build for Windows Desktop
ARM/ARM64.
Note: In order to build the ARM/ARM64 data DLL, you need to first build
x64/Release, as the ARM/ARM build uses the x64 bits in order to be able
to cross-compile for ARM/ARM64. This allows for completely building
ARM/ARM64 binaries using only x64 hardware.
The ARM/ARM64 builds require using a newer version of the Windows SDK
than 8.1, so they have a separate WindowsTargetPlatformVersion which
uses Windows 10 SDK version 10.0.16299.0 (aka RS3), which is the first
version of the Windows SDK to support building ARM64 desktop applications.
In addition this also greatly cleans-up the ICU4C ".vcxproj" files, in
order to remove redundant parts, fix inconsistencies, and make them more
readable. This introduces two new variables in the shared `*.props`
files: `IcuBinOutputDir` and `IcuLibOutputDir` in order to further
reduce the amount of duplicated lines in the individual ".vcxproj"
files themselves.
In the case several internal builtins defined by clang were not available,
ICU was replacing them by a stub implementation. But that was breaking
detection of availability of same methods in other parts of Chromium
(specifically in base/location.h).
Instead of that, this change creates ICU specific macros that will
map to those builtins when available, or to stub implementation if
not.
I.e. for the case of __has_builtin, previous implementation was
defining __has_builtin(x) as 0 in case it was not declared. With
new implementation, there is a macro UPRV_HAS_BUILTIN that maps
to __has_builtin if available, or 0 if not.
Adds `U_ASSERT` check before using `m->lock()` to make allocation issues
more apparent at least in debug builds.
There is probably quite a few places like this, but let's try fixing
broken windows.
