Date: Sun, 18 Dec 2022 10:25:22 -0500 From: Rich Felker <dalias@...c.org> To: Domingo Alvarez Duarte <mingodad@...il.com> Cc: 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". Everyone's already covered the reason this is not a bug, but to shed some light on possible motivations for not implementing ato* as wrappers around strto*: Aside from making these functions somewhat smaller when static linked into tiny programs, writing the conversion with arithmetic that overflows on out-of-bounds inputs rather than handling it as an error case makes it so that a build of libc with suitable sanitizers would automatically make ato* trap-and-crash on inputs that have undefined behavior via the undefinedness of the underlying arithmetic. To do this with strto* wrappers would require manually checking error cases and manual alignment of the trap cases with the specification, which would need review and testing to get the same benefit. That's not to say it *has to* be done this way. In lots of places in musl, we do just implement "junk functions" similar to the ato* family as wrappers around a modern "good function". But being that we already have it here, I see no reason to change to something that's worse in most ways. Rich
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.