5 ms·
The Linux man page (https://man7.org/linux/man-pages/man3/atoi.3.html#VERSIONS https://man7.org/linux/man-pages/man3/atoi.3.html#VERSIONS) says that POSIX.1 lea
by acidx 11mo ago
The Linux man page (https://man7.org/linux/man-pages/man3/atoi.3.html#VERSIONS https://man7.org/linux/man-pages/man3/atoi.3.html#VERSIONS) says that POSIX.1 leaves it unspecified. As you found out, it's really something that should be avoided as much as possible, because pretty much everywhere disagrees how it should behave, especially if you value portability.
sscanf() is not a good replacement either! It's better to use strtol() instead. Either do what Lwan does (https://github.com/lpereira/lwan/blob/master/src/lib/lwan-config.c#L156-L174 https://github.com/lpereira/lwan/blob/master/src/lib/lwan-co...), or look (https://cvsweb.openbsd.org/src/lib/libc/stdlib/strtonum.c?rev=1.8&content-type=text/x-cvsweb-markup https://cvsweb.openbsd.org/src/lib/libc/stdlib/strtonum.c?re...) at how OpenBSD implemented strtonum(3).
For instance, if you try to parse a number that's preceded by a lot of spaces, sscanf() will take a long time going through it. I've been hit by that when fuzzing Lwan.
Even cURL is avoiding sscanf(): https://daniel.haxx.se/blog/2025/04/07/writing-c-for-curl/ https://daniel.haxx.se/blog/2025/04/07/writing-c-for-curl/
- MathMonkeyMan 11mo agoIf your use case can have C++, then [std::from_chars][1] is ideal. Here's gcc's [implementation][2]; a lot of it seems to be handling different bases. [1]: https://en.cppreference.com/w/cpp/utility/from_chars.html https://en.cppreference.com/w/cpp/utility/from_chars.html [2]: https://github.com/gcc-mirror/gcc/blob/461fa63908b5bb1a44f12303676d9eb83f5dbdd3/libstdc%2B%2B-v3/include/std/charconv#L562 https://github.com/gcc-mirror/gcc/blob/461fa63908b5bb1a44f12...