Closed ghost closed 1 year ago
Nice find! Will look into this later today :)
Sorry, ran out of time. Will have a look during the week.
Looking into this now. There's already checks where I'm rejecting numbers that are unrepresentable, just that there's a gap in the sign handling logic for exactly INT64_MIN 😅
You're right :smile: I'm almost sorry for reporting it. But it's still worthwhile to eliminate an undefined codepath I guess.
Eh, I'm happy you did. It's probably not that uncommon a value in the wild since people often use INT_MIN/MAX as sentinels for various things.
Environment
toml++ version and/or commit hash:
version 3.2.0, commit 698285d9b2f3f6756fcdab8b93f60352325764e1 on master branch
Compiler:
GCC 10.2.1
C++ standard mode:
-std=c++17
Target arch:
x86_64
Library configuration overrides:
none
Relevant compilation flags:
-std=c++17 -O2 -fsanitize=undefined -fsanitize=address
Describe the bug
When parsing the integer value
-9223372036854775808
(i.e. -2^63), the parser constructs an intermediate uint64_t value 9223372036854775808. It then casts this value to int64_t, which has implementation defined behaviour and results in -9223372036854775808. It then attempts to multiply this value by -1 which has undefined behaviour because the result can not be represented as int64_t.Steps to reproduce (or a small repro code sample)
Compile as follows:
g++ -Iinclude -Wall -Wextra -Wpedantic -Werror -std=c++17 -O2 -fsanitize=undefined -fsanitize=address -o tt_decoder toml-test/tt_decoder.cpp
Then run
tt_decoder
on the following TOML document:The program prints the following error message:
Additional information