mirror of
https://github.com/nlohmann/json.git
synced 2026-09-06 16:27:59 +00:00
Niels Lohmann
ab8aa8458b
huge_string_t doubles as basic_json's StringType, so it is used not only for the JSON string value under test but also for object keys (e.g. "s", "nested"). Making size() unconditionally lie about being huge therefore inflated the keys' reported sizes as well, pushing the running totals computed while walking the BSON document (calc_bson_object_size and friends in binary_writer.hpp) past what a 32-bit std::size_t can hold. On 64-bit platforms this happens to still produce a working (if needlessly large) result, but on 32-bit platforms (e.g. the mingw x86 CI job) the size_t arithmetic silently wraps around: for the "document" test this merely surfaces the wrong number in the exception message, but for the "string" test the wrapped total happens to fall back under INT32_MAX, so the intended out_of_range.412 guard is skipped entirely and the code goes on to actually write ~2 GiB worth of characters from the key's real, tiny buffer - which is what raised the reported "vector::_M_range_insert" exception instead of a controlled 412. Make the fake-huge size opt-in via huge_string_t::as_huge() and only apply it to the string value under test, leaving keys at their real (small) size. This keeps every intermediate size well within 32-bit size_t range on any platform, matching how huge_binary_t already avoids the same trap (it is only ever used as the BSON value type, never as a key). Expected out_of_range.412 messages are updated accordingly. Signed-off-by: Niels Lohmann <mail@nlohmann.me>