https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605
Bug ID: 110605
Summary: Possible lack of error checking in lto-common.cc ?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I am investigating a valgrind error in the lto code:
==910546== Conditional jump or move depends on uninitialised value(s)
==910546== at 0x71DF70: lto_resolution_read (lto-common.cc:2126)
==910546== by 0x71DF70: lto_file_read (lto-common.cc:2351)
==910546== by 0x71DF70: read_cgraph_and_symbols(unsigned int, char const**)
(lto-common.cc:2805)
==910546== by 0x706FA9: lto_main() (lto.cc:654)
==910546== by 0xCE0F39: compile_file() (toplev.cc:444)
==910546== by 0x6C26F9: do_compile (toplev.cc:2126)
==910546== by 0x6C26F9: toplev::main(int, char**) (toplev.cc:2282)
==910546== by 0x6C3FDA: main (main.cc:39)
The line 2126 is
^d4ba3b369 (Jonathan Wakely 2022-11-01 09:48:41 +0000 2126) if
(strcmp (lto_resolution_str[j], r_str) == 0)
I had a look around and I noticed just before this is:
^d4ba3b369 (Jonathan Wakely 2022-11-01 09:48:41 +0000 2106) fscanf
(resolution, "%u", &num_symbols);
It has no error checking. I think this will produce a warning with
-D_FORTIFY_SOURCE=1.
I can't prove the lack of error checking on the fscanf line is related to
my valgrind problem, but it does look suspicious. Suggest fix.
