Overflow converting -2147483648 to int when using MPZ
When MICROPY_LONGINT_IMPL == MICROPY_LONGINT_IMPL_MPZ, calling mp_obj_get_int() for a Python variable that contains the value -2147483648 results in an overflow converting long int to machine word error.
If MICROPY_LONGINT_IMPL == MICROPY_LONGINT_IMPL_LONGLONG instead, the conversion works OK.
Is the MPZ overflow check incorrect?
tests/extmod/json_loads: Add test cases for LONGINT parse.
Summary
These tests cover the use of mp_obj_new_int_from_str_len when mp_parse_num_integer overlows the SMALLINT limit.
I recently discovered that the LONGLONG implementation of mp_obj_new_int_from_str_len is broken. It does not take the sign into account, and assumes the string buffer is nul-terminated, which is wrong as mp_parse_num_integer is mostly used on vstr buffers.
However, there is currently no test case that checks for these specific aspects of overflow handling: when integration tests are run with MICROPY_LONGINT_IMPL set to MICROPY_LONGINT_IMPL_LONGLONG, all tests pass.
So this pull requests adds coverage for these corner cases.
As there is currently no variant that uses MICROPY_LONGINT_IMPL_LONGLONG in the standard integration tests, adding these test cases will not cause a build issue.
Adding a MICROPY_LONGINT_IMPL_LONGLONG variant to the integration tests and fixing the longlong parsing code should be discussed first and handled in separate pull requests, but at least these test cases will properly document the problematic cases.
Testing
This code test code has been tested on Unix ports (LONGLONG and MPZ).
With MPZ, the test case pass
With LONGLONG, the test case fails