|
Message-ID: <20221218095852.GA2551@voyager> Date: Sun, 18 Dec 2022 10:58:52 +0100 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Subject: Re: Bug in atoll strtoll, the output of then differ On Sun, Dec 18, 2022 at 10:32:10AM +0100, Domingo Alvarez Duarte wrote: > Hello ! > > Doing some work with emscripten with this project > https://github.com/mingodad/CG-SQL-Lua-playground I was getting some errors > with the usage of "atoll" and with this small program to compare the output > of "musl" and "glibc" I found what seems to be a bug in "atoll" because with > "musl" it gives a different output than "strtoll". > > ===== > > #include <stdio.h> > #include <stdlib.h> > > int main(int argc, char *argv[]) > { > const char *s = "9223372036854775808"; > long long ll = atoll(s); > long long ll2 = strtoll (s, (char **) NULL, 10); > int imax = 0x7fffffff; > printf("%s : %lld : %lld : %d : %d\n", s, ll, ll2, imax, ll <= imax); > return 0; > } > > ===== > > Output from "glibc": > > ===== > > 9223372036854775808 : 9223372036854775807 : 9223372036854775807 : 2147483647 > : 0 > > ===== > > Output from "musl": > > ===== > > 9223372036854775808 : -9223372036854775808 : 9223372036854775807 : > 2147483647 : 1 > > ===== > > Cheers ! > Well, your problem here is that ato* behavior on error is not defined. The C standard explicitly excepts behavior on error from the requirement that these functions return the same thing as their strto* counterparts, and §7.24.1 (of C23) explicitly states that behavior in that case is undefined. This means that a test case is wrong; no result is defined. Actually, a crash would be acceptable behavior. This also means that when I return to work next year, I should really go through my code base and replace all ato* calls with their strto* counterparts for that reason alone. Ciao, Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.