[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20221218152521.GC15716@brightrain.aerifal.cx>
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.
