https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119052
--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:dfdbad87aeb2deff9e13a394659ac7b37173648a commit r15-7772-gdfdbad87aeb2deff9e13a394659ac7b37173648a Author: Jakub Jelinek <ja...@redhat.com> Date: Sat Mar 1 16:09:07 2025 +0100 input: Fix UB during self-tests [PR119052] As the comment in check_line says: /* get_buffer is not null terminated, but the sscanf stops after a number. */ the buffer is not null terminated, there is line.length () to determine the size of the line. But unlike what the comment says, sscanf actually still requires null terminated string argument, anything else is UB. E.g. glibc when initializing the temporary FILE stream for the string does if (size == 0) end = strchr (ptr, '\0'); and this strchr/rawmemchr is what shows up in valgrind report on cc1/cc1plus doing self-tests. The function is used only in a test with 1000 lines, each containg its number, so numbers from 1 to 1000 inclusive (each time with '\n' separator, but that isn't included in line.length ()). So the function just uses a temporary buffer which can fit numbers from 1 to 1000 as strings with terminating '\0' and runs sscanf on that (why not strtoul?). Furthermore, the caller allocated number of lines * 15 bytes for the string, but 1000\n is 5 bytes, so I think * 5 is more than enough. 2025-03-01 Jakub Jelinek <ja...@redhat.com> PR other/119052 * input.cc (check_line): Don't call sscanf on non-null terminated buffer, instead copy line.length () bytes from line.get_buffer () to a local buffer, null terminate it and call sscanf on that. Formatting fix. (test_replacement): Just allocate maxline * 5 rather than maxline * 15 bytes for the file. Formatting fix.
