Parsing Integers in C

https://news.ycombinator.com/rss Hits: 1
Summary

In the standard libc API set there are multiple functions provided that do ASCII numbers to integer conversions. They are handy and easy to use, but also error-prone and quite lenient in what they accept and silently just swallow. atoi atoi() is perhaps the most common and basic one. It converts from a string to signed integer. There is also the companion atol() which instead converts to a long. Some problems these have include that they return 0 instead of an error, that they have no checks for under or overflow and in the atol() case there’s this challenge that long has different sizes on different platforms. So neither of them can reliably be used for 64-bit numbers. They also don’t say where the number ended. Using these functions opens up your parser to not detect and handle errors or weird input. We write better and stricter parser when we avoid these functions. strtol This function, along with its siblings strtoul() and strtoll() etc, is more capable. They have overflow detection and they can detect errors – like if there is no digit at all to parse. However, these functions as well too happily swallow leading whitespace and they allow a + or – in front of the number. The long versions of these functions have the problem that long is not universally 64-bit and the long long version has the problem that it is not universally available. The overflow and underflow detection with these function is quite quirky, involves errno and forces us to spend multiple extra lines of conditions on every invoke just to be sure we catch those. curl code I think we in the curl project as well as more or less the entire world has learned through the years that it is usually better to be strict when parsing protocols and data, rather than be lenient and try to accept many things and guess what it otherwise maybe meant. As a direct result of this we make sure that curl parses and interprets data exactly as that data is meant to look and we error out as soon as we detect the data t...

First seen: 2025-11-13 21:49

Last seen: 2025-11-13 21:49