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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31458 invoked from network); 18 Dec 2022 09:59:10 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 18 Dec 2022 09:59:10 -0000 Received: (qmail 3594 invoked by uid 550); 18 Dec 2022 09:59:06 -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 3554 invoked from network); 18 Dec 2022 09:59:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1671357533; bh=IHHBHCLp9l0AVrI96RnvLdwEP+wVD01KkKkW+y1daMU=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=eY3phoIUjx+C5C8fILqYYoH4jRk2WvjJ2B72IhsndnAevUgxOXXTjMhaViQ/9bs3+ KTGtLW6YoSWNsiCGGHKO3lckUcaOQhr7hlelm70ZmkAP+ag2P828ipOXECYc/NXQjy CmvYV21rH/KTczhuhikkVZ58sqndO1JgaeHoajsyoOBux1ACRA6DgZ/H0xFidArTEY srXgJyBGdJJG5jQmQbWGISUoZ54YtN111frabDtW6g9bn9Z8q7ptmjS5m6usXr5zjo se81t7VPN0VU9HO/ucZx9eb5+cb+T48WNIP9hCi69uLDQL9097d+Q8QLiaSToDkm+p VsJc6Y7MkvYHQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Sun, 18 Dec 2022 10:58:52 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20221218095852.GA2551@voyager> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:TR61uqRPDNo5UhCaaODkh0ftXc+YQ3yRX53mk8ptx9dnENPRcGN N60vVwFp9W36MTLXXJf6rUrrA6KVmJOdrrOJlCmZ8yKefxzVfCcfwzd4fc1l2eFJGq+RuRj n4p/M18ZN1U3ApYF1Fjm3HFMSmuHIXyXclqb69hbloVlozXxtzphNGJWT6XCvDlUXKVPbMl NUw+VZ1AJWvwIF408AjTA== UI-OutboundReport: notjunk:1;M01:P0:yI97VTAWB6w=;HWlBenEE0PGygwkmW/mvlJnH0Xw mXs0nLAAwmxo5La8qrG1Rt32gsqdZ+0hWLgGRtfaouYkDEipYjLDLwh7wDlTrHnk6qN+oIYjh T8KTYIqH1uesKy2Oz3Hgg2lYwPnQWLzLWolJ0PLb+pt3R8DkolWYO8aG6A/vdOxao5HTRYs4K Ed3pIpTj5Ciu0tAjm9LvMlxnyMXQgiP8F7C7Kh4rdq7u6Tth/TYVfJUgcqFsrRJ5RS0lSGoJc 4wcBKh869MU+RTN93/3ZsajeFhh+ep0474aF2GIwsprMgDCwqqmbqnoULgI/Twflv6dMlurFg 3cT/5jduizQsbwyFbwDvbJ7U4Ic9FJOoGmvvW1bv5NIRW6MpLiwxXsq46WWtN7r4fGIGlifVU zESUbyaSzM5yLdDHB7a3xv2xB62zWBizeD8GtFEiEzMT39vf8ie6h4un1zpgqxnQomc3tQmQ3 mhlAWbd2J1i9esBmg5btcTsR4+07iof3t1U2VHxBOwD3zNcYRHHybeQ6bnVmzKVTKwXWphaDs rLSVW8McbUxTULTkN5KNHjd3BozDMFInecY7xM681IgGzIFm729sDdUFH9TtvjyXWKze2oR30 iAuznKBrWLcjeIJEfm2+OzREe7BF0VBaOXRdboUPEeMI69qEExuEmxtzKQ/ITiqgLeT3P5cTP MzrC2VrNSwiOUuPSr4HWVHy3diITCcyW6STD3ZoMf4hi64EokLVgvYRL2xA9jPuTf3EKnCHQH 9rp6JPXSLVJDEr4Zl6WWZjssV+upnDXgWiYOcf3QBa7Kh6aCSHnfm889Elr7u5pFkIwIKhJ0h fJRkbWB9VpUvOCRWcb/JGBU4Atem8gN7K/q5cgHDj6sCvzB8BEC8bTQdPgTX7B+EYvfzG5AC9 l19rehPVkujCOu3I2Zrb+IRW3iAErM16KcetHgHKlEBcsaKSJuVLIGynDq6bUNQ3oWaDIfxjF Jmv+iQ== 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 err= ors > with the usage of "atoll" and with this small program to compare the out= put > of "musl" and "glibc" I found what seems to be a bug in "atoll" because = with > "musl" it gives a different output than "strtoll". > > =3D=3D=3D=3D=3D > > #include > #include > > int main(int argc, char *argv[]) > { > =A0=A0 =A0const char *s =3D "9223372036854775808"; > =A0=A0 =A0long=A0 long ll =3D atoll(s); > =A0=A0 =A0long long ll2 =3D strtoll (s, (char **) NULL, 10); > =A0=A0 =A0int imax =3D 0x7fffffff; > =A0=A0 =A0printf("%s : %lld : %lld : %d : %d\n",=A0 s, ll, ll2, imax, ll= <=3D imax); > =A0=A0 =A0return 0; > } > > =3D=3D=3D=3D=3D > > Output from "glibc": > > =3D=3D=3D=3D=3D > > 9223372036854775808 : 9223372036854775807 : 9223372036854775807 : 214748= 3647 > : 0 > > =3D=3D=3D=3D=3D > > Output from "musl": > > =3D=3D=3D=3D=3D > > 9223372036854775808 : -9223372036854775808 : 9223372036854775807 : > 2147483647 : 1 > > =3D=3D=3D=3D=3D > > 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 =A77.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