tree 33ecba4fb052e201618f230a648fdcd2f2475f4a
parent dacafb696449c3f592deefc1745c77704ea396a6
author Jan Kundrát <jan.kundrat@cesnet.cz> 1720292123 +0200
committer Michal Vasko <mvasko@cesnet.cz> 1721123105 +0200

fix parsing of numbers within XML-encoded anyxml

This was caught by the libyang-cpp test suite. On Windows/MSVC, an
anyxml snippet that was parsed from this XML:

 <ax xmlns="http://example.com/coze"><x>1</x><x>2</x><x>3</x></ax>

...would get printed like this:

 {"example-schema:ax":{"x":["1","2","3"]}}

...while the correct form is:

 {"example-schema:ax":{"x":[1,2,3]}}

This was caused by a change in `lydxml_get_hints_opaq` which probably
tried to silence a compiler warning. The code wrongly assumed that the C
`long` will be able to hold `UINT32_MAX`, which is not the case on
Windows where `long` has the same range as `int32_t`. As a result, when
the XML is parsed, these numeric values are compared against -1 on
Windows, and against 4294967295 on many other platforms, and therefore
any positive number was tagged with the hint of "this needs a 64bit
serialization" on Windows, which in turn triggers printing these values
as quoted string in JSON.

The fix simply makes sure that we never perform a narrowing conversion
from a constant. I was looking for a way of using explicitly sized types
(i.e., int64_t in this case), but there's only `strtoll` in C. The
alternative would be `sscanf(... SCNd64 ...)`, but the semantics is
subtly different when it comes to whitespace.

The bisecting process was non-trivial for me because the workflow which
bypasses CI introduced a test regression (fixed by commit 7ebd607ee,
"test UPDATE message changed") and a temporary Windows breakage (fixed
by commit a1ecc1695, "compat BUGFIX regression in win timegm support").
Instead of a simple `git bisect`, this required some manual patch
backporting.

Fixes: 21eaa39f9 libyang BUGFIX type size problems