Re: [musl] Bug in atoll strtoll, the output of then differ

[Markus Wichmann <nullplan@gmx.net>]

On Sun, Dec 18, 2022 at 11:22:59AM +0100, Domingo Alvarez Duarte wrote:
> Here is the "glibc" implementation of "atoll":
>
> =====
>
> /* Convert a string to a long long int.  */
> long long int
> atoll (const char *nptr)
> {
>   return strtoll (nptr, (char **) NULL, 10);
> }
>
> =====
>
> With that there is no way for get different results from "atolll" and
> "strtoll".
>
> Cheers !
>

That's precisely why I would like for programmers to learn some Pascal
at some point in their lives, so they start to understand that interface
and implementation are two separate things.

Yes, that is a nice implementation up there. The interface for atoll
however comes from the C standard, and it says:

| 7.24.1 Numeric conversion functions
| 1 The functions atof, atoi, atol, and atoll need not affect the value of the integer expression errno
| on an error. If the value of the result cannot be represented, the behavior is undefined.
| [...]
| The atoi, atol, and atoll functions convert the initial portion of the string pointed to by nptr to
| int, long int, and long long int representation, respectively. Except for the behavior on error,
| they are equivalent to
| atoi: (int)strtol(nptr, nullptr, 10)
| atol: strtol(nptr, nullptr, 10)
| atoll: strtoll(nptr, nullptr, 10)

Entering 2^63 into atoll() (when long long int is a 64 bit type) is an
error that invokes undefined behavior.  Explicitly undefined behavior.
Some implementations choose to deal with this by implementing the
protections from strtoll() (for example by calling strtoll()). Some
implementations don't. This is an implementation detail. The application
cannot know what will happen, and should not make assumptions about what
will happen. It should only call the ato* functions on known valid
input. If it does not know that the input is valid, it should not call
ato*.

Ciao,
Markus