Read unitsTest.txt, prepare to run unit tests.
PR: https://github.com/sffc/icu/pull/20
Commit: 9f65f41f183ded57efdf4f7c0cdf56c02e441024
No-op/cosmetic: reformat with clang-format ident:4 line-length:105.
PR: https://github.com/sffc/icu/pull/25
Commit: 4be0a2bc55fc3567f790a53cc988abd4c3508419
Parse unitPreferencesTest.txt preparing to run data-driven tests
PR: https://github.com/sffc/icu/pull/26
Commit: 9e021f9b6fbee06283ef4c45dbfe5c7b3abd2dbf
Improve test output: no more fprintfs.
PR: https://github.com/sffc/icu/pull/34
Commit: 12a5289238d68e3aa184727d7d7af55d386613c7
Update to latest CLDR test files: b7a23f3f41 CLDR-13587.
PR: https://github.com/sffc/icu/pull/33
Commit: 44e9afb32187529a4599548c42f70c7deb3e46bf
Add unitsdata.cpp, getConversionRatesInfo, and unit tests.
PR: https://github.com/sffc/icu/pull/31
Commit: ca34233e0804c1175f210e5557bb984da2eab244
Update unitsTest.txt and unitPreferencesTest.txt from current CLDR master
PR: https://github.com/sffc/icu/pull/41
Commit: be7f69941ddf4373e9d66149e95f5b8345d7de5d
This PR fixes
ICU-21043 Erroneous date display in indian calendar of all dates prior to 0001-01-01.
ICU-21044 Hebrew Calendar calculation is incorrect when the year < 1
ICU-21045 Erroneous date display in islamic and islamic-rgsa calendars of all dates prior to 0622-07-18.
ICU-21046 Erroneous date display in islamic-umalqura calendar of all dates prior to -195366-07-23.
The problem in the indiancal.cpp is
* ICU-21043 the gregorian/julain convesion is wrong. Swith to use
i18n/gregoimp.h fix the problem.
The problem in the hebrwcal.cpp is
* ICU-21044 Use ClockMath::floorDivid to replace x / y for x maybe < 0
also need to fix incorrect value in test file
The problem in the islamcal.cpp:
* ICU-21045: The math of % negative number for year and month is wrong.
* ICU-21046: Not use int64_t methods and caused int32_t overflow while the year is a
huge negative number. Cast to int64_t to force using the int64_t version
for the math fix the problem.
Also add tests to exhaust test 8000 years for all calendar. In quick
mode, only test 2.5 years.
Switch to 0-based month. fix TZ for test.
These two calls to uloc_getKeywordValue() write to the buffer "id" which
then immediately after is overwritten by calls to idForLocale() so they
can simply be removed without any loss of functionality.
This eliminates the need for a scratch buffer in Locale::getKeywordValue()
and also the need for counting bytes required in uloc_getKeywordValue(),
something that ByteSink will now handle correctly.
Move them UniqueCharStrings and CharStringMap from
loclikelysubtags.{h,cpp} to separate header files
so so we can reuse them to implement
https://github.com/unicode-org/icu/pull/1254
Change to use the Windows 10 SDK for Win32 (Win7) builds on the VS2019 ADO images.
The Windows 10 SDK is backwards compatible to Windows 7, if WINVER and
_WIN32_WINNT are set before compiling.
Clean up the vcxproj files from VC7.1
The one single caller of _getVariantEx() is _getVariant() and this in
turn only has 3 callers, one of which is commented out (so it can be
deleted), one of which doesn't actually do anything (so it too can be
deleted) and one which can be replaced by inlining the use of
CheckedArrayByteSink.
This also allows _getVariantEx() to be renamed to _getVariant() as it's
the only such function left now.
Fix kilogram parsing: ignore 'kilogram' as a stem, we have 'gram'.
Failures in the added unit test before the fix: withSIPrefix resulted
in 'microkilogram', and kilogram's prefix was considered to be
"ONE" (i.e. 10^0).
The complicated buffer allocation code is inherited from times past but
no longer serves any purpose, it's now possible to instead simply call
the CharString copy constructor.
By always calling the dynamic memory allocation implementation directly
instead, the fixed memory buffer boundary gets pushed one step further
towards the edges.
By always calling the dynamic memory allocation implementation directly
instead, the fixed memory buffer boundary gets pushed one step further
towards the edges.
By always calling the dynamic memory allocation implementation directly
instead, the fixed memory buffer boundary gets pushed one step further
towards the edges.
Document the fact
uloc_getDisplay(Language|Script|Country|Variant|Keyword|KeywordValue)
would fallback with the code, case canonicalied in same cases, and
set the status to U_USING_DEFAULT_WARNING.
No change to the implementation behavior. Only complete the missing
comments and tweak line wrap, remove double spaces and add test to
validate this pre-existing behavior that I added the documents now.
- MaybeStackVector::emplaceBackAndCheckErrorCode()
- MemoryPool::createAndCheckErrorCode()
Started with cherry-picks of:
3b505977c0e82659896125698389b59eabe50b14
63b93bde5c4c9fe030d490d5d448087aa0d4e5fd
Measure: initialize unit to nullptr, and don't dereference it if it is
nullptr.
NumberFormatterImpl::writeAffixes: U_ASSERT not-null, instead of
segfaulting for coding mistakes.
Downstream bug https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15505
Fix Fuzzer-detected Use-of-uninitialized-value in isMatchAtCPBoundary
To test to show the bug in the new test case, configure and build with
CFLAGS="-fsanitize=memory" CXXFLAGS="-fsanitize=memory" ./runConfigureICU \
--enable-debug --disable-release Linux --disable-layoutex
Test with
cintltst /tsutil/custrtst
In the test data from rbbitst.txt, two or more adjacent boundary markers with
no intervening test data were accepted, with no indication of a problem.
This situation occurred, as described in bug ICU-21178, with a bad import of
some test cases from CLDR. PR #1194 corrected the problem with the test data
in ICU4C. This PR adds code to flag this situation in the test data, and
also propagates the data fix to ICU4J's copy of rbbitst.txt.
Change the mapping from rule number to boundary position to use a simple array
instead of a linear search lookup map.
Look-ahead rules have a preceding context, a boundary position, and following context.
In the implementation, when the preceding context matches, the potential boundary
position is saved. Then, if the following context proves to match, the saved boundary is
returned as an actual boundary.
Look-ahead rules are numbered, and the implementation maintains a map from
rule number to the tentative saved boundary position.
In an earlier improvement to the rule builder, the rule numbering was changed to be a
contiguous sequence, from the original sparse numbering. In anticipation of
changing the mapping from number to position to use a simple array.
CharString, when asked, appends U_FILE_SEP_CHAR at the end of the string
it holds, if it won't find U_FILE_SEP_CHAR or U_FILE_ALT_SEP_CHAR there.
The problem starts if the dir variable uses
U_FILE_ALT_SEP_CHAR which is not equal to U_FILE_SEP_CHAR. Then the
resulting path could look like this
../data\
instead of this
../data/
This patch uses U_FILE_SEP_CHAR unless it detects that the dir variable
doesn't use it, and uses U_FILE_ALT_SEP_CHAR instead.
Fix a clang compiler warning and a potential undefined behavior arising
from casting an out-of-range double to an int. See the Jira ticket for a
more detailed description of the problem.
This PR is to fix the immediate problem. Longer term, the function
may be replaced entirely - see issue ICU-21147.
