diff options
author | Michael Jones <michaelrj@google.com> | 2024-10-18 15:48:15 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-10-18 15:48:15 -0700 |
commit | 0afe6e42fbab25b3b0d35921774bf2584bcd0d74 (patch) | |
tree | ae8be6f2ce73a7e01b0951d3342c3297aef12b35 /lldb/source/Interpreter/CommandInterpreter.cpp | |
parent | b35b5838094cdae897519a5f404a18e613041cff (diff) | |
download | llvm-0afe6e42fbab25b3b0d35921774bf2584bcd0d74.zip llvm-0afe6e42fbab25b3b0d35921774bf2584bcd0d74.tar.gz llvm-0afe6e42fbab25b3b0d35921774bf2584bcd0d74.tar.bz2 |
[libc] Scanf shouldn't match just "0x" for hex int (#112440)
Scanf parsing reads the longest possibly valid prefix for a given
conversion. Then, it performs the conversion on that string. In the case
of "0xZ" with a hex conversion (either "%x" or "%i") the longest
possibly valid prefix is "0x", which makes it the "input item" (per the
standard). The sequence "0x" is not a "matching sequence" for a hex
conversion, meaning it results in a matching failure, and parsing ends.
This is because to know that there's no valid digit after "0x" it reads
the 'Z', but it can only put back one character (the 'Z') leaving it
with consuming an invalid sequence.
(inspired by a thread on the libc-coord mailing list:
https://www.openwall.com/lists/libc-coord/2024/10/15/1, see 7.32.6.2 in
the standard for more details.)
Diffstat (limited to 'lldb/source/Interpreter/CommandInterpreter.cpp')
0 files changed, 0 insertions, 0 deletions