diff options
author | Mark Dickinson <dickinsm@gmail.com> | 2022-09-25 09:55:33 (GMT) |
---|---|---|
committer | GitHub <noreply@github.com> | 2022-09-25 09:55:33 (GMT) |
commit | f5f047aa628caeca680745c55e24519f06aa6724 (patch) | |
tree | 55a32b33e0c24c2f1b6da99c5ebca8b687a9f884 /Python/errors.c | |
parent | 817fa28f81eed43539fad2c8e696df954afa6ad7 (diff) | |
download | cpython-f5f047aa628caeca680745c55e24519f06aa6724.zip cpython-f5f047aa628caeca680745c55e24519f06aa6724.tar.gz cpython-f5f047aa628caeca680745c55e24519f06aa6724.tar.bz2 |
gh-96735: Fix undefined behaviour in struct unpacking functions (#96739)
This PR fixes undefined behaviour in the struct module unpacking support functions `bu_longlong`, `lu_longlong`, `bu_int` and `lu_int`; thanks to @kumaraditya303 for finding these.
The fix is to accumulate the bytes in an unsigned integer type instead of a signed integer type, then to convert to the appropriate signed type. In cases where the width matches, that conversion will typically be compiled away to a no-op.
(Evidence from Godbolt: https://godbolt.org/z/5zvxodj64 .)
To make the conversions efficient, I've specialised the relevant functions for their output size: for `bu_longlong` and `lu_longlong`, this only entails checking that the output size is indeed `8`. But `bu_int` and `lu_int` were used for format sizes `2` and `4` - I've split those into two separate functions each.
No tests, because all of the affected cases are already exercised by the test suite.
Diffstat (limited to 'Python/errors.c')
0 files changed, 0 insertions, 0 deletions