aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Interpreter/CommandInterpreter.cpp
diff options
context:
space:
mode:
authorMichael Jones <michaelrj@google.com>2024-10-18 15:48:15 -0700
committerGitHub <noreply@github.com>2024-10-18 15:48:15 -0700
commit0afe6e42fbab25b3b0d35921774bf2584bcd0d74 (patch)
treeae8be6f2ce73a7e01b0951d3342c3297aef12b35 /lldb/source/Interpreter/CommandInterpreter.cpp
parentb35b5838094cdae897519a5f404a18e613041cff (diff)
downloadllvm-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