Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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 7ebd607, "test UPDATE message changed") and a temporary Windows breakage (fixed by commit a1ecc16, "compat BUGFIX regression in win timegm support"). Instead of a simple `git bisect`, this required some manual patch backporting. Fixes: 21eaa39 libyang BUGFIX type size problems
- Loading branch information