The manpage is clear enough:

```
RETURN VALUE
       The converted value or 0 on error.
[…]
No checks for overflow or underflow are done.
```

This is not really true. atoi() uses strtol() to convert from string to long, and the results may be under or overflow, in which case strtol() returns LONG_MIN and LONG_MAX, respectively.

LONG_MIN cast to `int` is 0, which lives up to the manpage just fine ("0 on error"), assuming underflow is an error.

LONG_MAX cast to `int` is -1.


So the behavior doesn't violate POSIX. But is surprising. And arguably is incorrectly documented. There is, in fact, a range check, but but against long, not int. "Error" is not defined in the manpage. Is over/underflow an error?

It's kinda handled, kinda not, with the effect that over and underflow have different return values.


For atol() range checks are fully done. The strtol() manpage documents it, per above.


It's not clear to me what the right fix is, here. Because enough code relies on the current (IMO in the case of atoi() broken)) behavior maybe a clarification to the manpage is in order, to say:
1. Instead of "No checks for overflow or underflow are done" say "for atoi() the return value in case of under/overflow is undefined".
2. For atol() document the current behavior of "for atol() and atoll() under/overflow is returned as LONG_MIN/LONG_MAX and LLONG_MIN/LLONG_MAX, respectively".

(2) seems safe as this is already the documented behavior of strtol().


My research/rant on the properties of parsing and casting integers:

https://blog.habets.se/2022/10/No-way-to-parse-integers-in-C.html
https://blog.habets.se/2022/11/Integer-handling-is-broken.html