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 13789 invoked from network); 18 Dec 2022 11:10:27 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 18 Dec 2022 11:10:27 -0000 Received: (qmail 7526 invoked by uid 550); 18 Dec 2022 11:10:23 -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 7490 invoked from network); 18 Dec 2022 11:10:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1671361810; bh=0xZdpToUzggBvj1WKB9J/QhA3+lytinDKgW6qZaU4bE=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=CBAg4OFD18WiHayA+VR5Xy5F/o2iBSxV/STYj0YjgdR78WqDPi6zlqtdFTPNXkqIJ NpFG4wCnxIcBuTzIOz3tNFYq4UAaSesSqq+niBvf0Z3OFkEp4/WpSFsFRs2kNbWL8P DvXn55r2FZ7BrviCh/S0pMXiAJUH04Tx4vrgjZhQmqJC0izLhpa47emsZQzLVefuot T1BIWUMZkYIry8twyEFRBkqrTl+yz4swFNdyc5AkhheO8/2IUDzGMzCd59L19QWiBy zBY0su6dXBByFJEmNohBgPoF4t3rm938VtxNwEtDJX5DFp40SeBT9eKtVXMNFgbEdg 7Spri4gcd6WXw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Sun, 18 Dec 2022 12:10:08 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20221218111008.GB2551@voyager> References: <20221218095852.GA2551@voyager> <1499b0ba-f828-6922-a620-24971fb64c8b@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1499b0ba-f828-6922-a620-24971fb64c8b@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:WYp1zFpOc08+NV0USlzC+QkpmU4DBsL7RQRXh6odOlUFHCwHbJI Zw8FnSk9O65ifKzprVUFWJuwpFEia29/SM0p88yK9Fmpt7kwY0FHc/n41cxwBwvuGIwqAtJ hbIbBRJEe3fJ5MhrsE8RDzSBCu3RPuS7E1hfsqc3phHSKPouC+ctzIQeTz8ag2AXs2RDIft XKzArNja/SmJnJrLlrnBA== UI-OutboundReport: notjunk:1;M01:P0:58wme1lYReU=;/hcvZKnB78oI4HZVn1T8WqEKxL3 zrf8egTkWe7el1FLnBfaCf5plhICVe8R6B5XFITqw2Uwbkf90fb0z5+6uVczHLHhHmMOh8KM5 E+Nr622F7qTf6pcOwi1JlpYs+TUTlH1xwsfAtu+DqZYL8+UfTEJZuHkr7LhMXLm9lI2eO0jI2 GQEz0jb4f/CCp8KWvQbOetduvVneCgnP3TGh+YUcwNs58UcVxdSoq+LexfkTa9l2DnjKF4925 roRc0iHtuzJy9NP27mk01sr0cxbBRyJl9EaJU2loobrBkXY17NKM2bqORUya2Jfjtk5XoT+pu D6Ul7BT1KptUUTCCwn+7fqzqXSd1F/xKN8+HlyX+SFp3qGQEXeuistuGc4168LXnKeqw4+sJp HTVyTYOa6feG7rJ+7nm+vNC+Alzj59urjWwV/Rzb13HfHpy1VvGi2fPdbu4dKTCMHKQjv+5HX kzxuAMFF1dAfBWQtEhRfBeUhpV9xI4WBbO0ufq5OLO4fHbk8KW+5LvfFL5dlGnup1x/jGo1Ve 8LpR7Rtazm5iJ/v67vlecDcqXbTPD5R0DgF6RF51cO+0fFcVX/ckSMNWjlh2BBeyqHjsY6PFe 07LjHdRP8mSrtJwCCHj1/UcburhYODzXwuoBnbek79QrHveAN0faTyEvJ+mcsA3hy42qbjMjf 6lgvAjtjNA/DAnifHnZXaXLCwqeKwIAkaf2d6/otn+giFa2oXRVxnDglqUfknPFcOH3swsXZj bDWAWFbjciTt/7WBq0/jSvpcETUcw/i9bkAqBlcmpgR1fpKvXF4AXwryUWDxTywakxueJPcME tn6Luqw3ZYDZqoVEPUuk5EZzcOG3X92qI/2UwSTdmRTf44MNkmaNUbsCHk2JetLw1jUX+VhFe R/BJ9xznQ4Nn9m2ltFLUYxNgFi/cU8tNmNOJTSzU3WUNj+cXHaMeQiCPwaAfjZ6vnErvkAJze hxNG0xt7vhHBwJ6myacD40muxvE= Subject: Re: [musl] Bug in atoll strtoll, the output of then differ On Sun, Dec 18, 2022 at 11:22:59AM +0100, Domingo Alvarez Duarte wrote: > Here is the "glibc" implementation of "atoll": > > =3D=3D=3D=3D=3D > > /* Convert a string to a long long int.=A0 */ > long long int > atoll (const char *nptr) > { > =A0 return strtoll (nptr, (char **) NULL, 10); > } > > =3D=3D=3D=3D=3D > > With that there is no way for get different results from "atolll" and > "strtoll". > > Cheers ! > That's precisely why I would like for programmers to learn some Pascal at some point in their lives, so they start to understand that interface and implementation are two separate things. Yes, that is a nice implementation up there. The interface for atoll however comes from the C standard, and it says: | 7.24.1 Numeric conversion functions | 1 The functions atof, atoi, atol, and atoll need not affect the value of= the integer expression errno | on an error. If the value of the result cannot be represented, the behav= ior is undefined. | [...] | The atoi, atol, and atoll functions convert the initial portion of the s= tring pointed to by nptr to | int, long int, and long long int representation, respectively. Except fo= r the behavior on error, | they are equivalent to | atoi: (int)strtol(nptr, nullptr, 10) | atol: strtol(nptr, nullptr, 10) | atoll: strtoll(nptr, nullptr, 10) Entering 2^63 into atoll() (when long long int is a 64 bit type) is an error that invokes undefined behavior. Explicitly undefined behavior. Some implementations choose to deal with this by implementing the protections from strtoll() (for example by calling strtoll()). Some implementations don't. This is an implementation detail. The application cannot know what will happen, and should not make assumptions about what will happen. It should only call the ato* functions on known valid input. If it does not know that the input is valid, it should not call ato*. Ciao, Markus