The atoi function has undefined behavior if its argument is outside the range of int. Thus, GCC should not use it for any user input that might be outside that range. For example, -O4294967296 should act like -O3, but on 64-bit systems with glibc it acts like -O0 (glibc's atoi converts the return from strtol to int, thereby losing high bits). In most cases (like the above), using strtol and saturating for input out of range of int is probably appropriate, but some cases may need errors for large input. A helper function - like atoi, but saturating - may be appropriate.
Confirmed.
There are also uses of atol, atoll and atoq to eliminate. Also note some Ada code using atoi (surely there must be a more idiomatic Ada way of doing this?). It would be best to poison all these functions when the uses are eliminated. In some cases the use of atoi may be allowing a wider range of inputs (in terms of leading whitespace and trailing unrecognized characters) than should actually be allowed in the context. libiberty has a use of atoi in cplus-dem.c that is harmless (it's only used on a single-digit string) but pointless (C guarantees that the digit characters have consecutive integer values so you can just subtract '0', and this guarantee is already in C90).
Here is the list of files which currently use ato{l,ll,i,q} in whole of gcc source base gcc directory: ada/libgnat/s-crtl.ads ada/libgnat/s-stausa.adb ada/libgnat/s-stchop.adb ada/raise-gcc.c ada/sysdep.c c/gimple-parser.c collect2.c config/cris/cris.c config/frv/frv.c config/host-linux.c config/msp430/driver-msp430.c config/msp430/msp430-devices.c config/nds32/nds32-isr.c config/nios2/nios2.c config/rs6000/rs6000.c diagnostic.c fortran/error.c fortran/scanner.c genattrtab.c genautomata.c lto-wrapper.c lto/lto.c opts.c read-rtl-function.c read-rtl.c varasm.c libobjc directory: encoding.c gc.c libgfortran: io/write_float.def runtime/environ.c liboffloadmic: runtime/emulator/coi_device.cpp runtime/offload_host.cpp runtime/offload_target.cpp libvtv: vtv_rts.cc fixincludes: fixincl.c
Now that we have C++11 we could use std::stoi, std::stol, std::stoul etc. ... except that they throw exceptions to report out of range values :-( std::from_chars isn't available until C++17.
Note I filed PR 114540 for the usage in varasm.cc (decode_reg_name_and_count) as you can come up with a few testcases where we don't reject invalid registers # when we should.
>c/gimple-parser.c PR 114541 since I found a testcase . This is turning into a meta-bug so let's turn it into a full one then.
>read-rtl-function.c Someone most likely can come up with a testcase for this one using the RTL parser.
> opts.c > lto-wrapper.c > lto/lto.c These 3 are all about parsing of -flto=N option; PR 114542