From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32621 invoked from network); 18 Dec 2022 15:25:40 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 18 Dec 2022 15:25:40 -0000 Received: (qmail 18261 invoked by uid 550); 18 Dec 2022 15:25:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 18226 invoked from network); 18 Dec 2022 15:25:35 -0000 Date: Sun, 18 Dec 2022 10:25:22 -0500 From: Rich Felker To: Domingo Alvarez Duarte Cc: musl@lists.openwall.com Message-ID: <20221218152521.GC15716@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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