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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4118 invoked from network); 18 Dec 2022 10:23:16 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 18 Dec 2022 10:23:16 -0000 Received: (qmail 19505 invoked by uid 550); 18 Dec 2022 10:23:13 -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 19463 invoked from network); 18 Dec 2022 10:23:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=GsqEPcWYexDzsXNe1x7OMx3EdZ1RYzrrugIza3jQboo=; b=iw6nk/vMCTI6heipfZ0soo95PcM4jOgmlt8TId/HCkjbQCE+SS2nGnlqypoaENvpLT whoXfZS8Pzhu7S++/9YnJLJjrf8Hbg092sfDuS06RtzIC+CIEiRbFXB7V/RuQpSpha8J wUvOlbnb3Hb7kRGbZVG/HI0EuPz+0uTM6PixHNaMXPWb/r3YvbDRV7RgOP682u0hFh8q 5NZB312V33HGkU87fhfO0ugmfTEsG+F01gcvgfrmikVD/7sFCGc+DzIv6SSpRyG5wwI5 3cWaifzWdesPLEUA/PBTYB+rULhLAoL/IlEbZ+DZANp/tSE8XTFvJfy8zZfFP/JYPspP WxCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GsqEPcWYexDzsXNe1x7OMx3EdZ1RYzrrugIza3jQboo=; b=Qe7HdZH/Nr3lCconNCq8aAUzQ3ArFLZwE2ELxfCtfKXOuweY2wUGtzAo65C8xu2eoA RTkudmnK5UNRPv74IcgsvSB5HzEJoGa4PUnMYkdW1K7VgAEangpsP3yIEtdbimyk+YjE 4ZlPyEr0yvoIOd3M77blagoLZHxVlioiYXOYT7HrIdUO9fcFvD6x5sQ9q+Fn7z1N7Ept 394b8PuUU7qx+EkM77KDi1tUrJHwTPCl4vJKlkZAVWTa6bjND2noumRQyi0MlplIAz/E AcdlqZr+Ot3qQxBGgTLnVAydy7nmZWie/aqO7H9h1eXPIyrsuOXD2BOL6pjIM1lLtTBM VYAA== X-Gm-Message-State: ANoB5plr4tSQRGS82OxQypTTfCSwGdyC+Ofb4BIwPNaXa7x0i4O/CM14 hs6J5svsgbbi0fnmlLzpc+3vN59GPqQ= X-Google-Smtp-Source: AA0mqf5KE+ZejrGtBq7kz/toi7Zu09AlIZO+1YOIb5RTu8wldDB1hPdFegtMjaKgJWMfEV9udglJPw== X-Received: by 2002:a5d:694d:0:b0:242:1dbf:ae03 with SMTP id r13-20020a5d694d000000b002421dbfae03mr23551084wrw.60.1671358981006; Sun, 18 Dec 2022 02:23:01 -0800 (PST) Message-ID: <1499b0ba-f828-6922-a620-24971fb64c8b@gmail.com> Date: Sun, 18 Dec 2022 11:22:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US To: musl@lists.openwall.com References: <20221218095852.GA2551@voyager> From: Domingo Alvarez Duarte In-Reply-To: <20221218095852.GA2551@voyager> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [musl] Bug in atoll strtoll, the output of then differ Here is the "glibc" implementation of "atoll": ===== /* Convert a string to a long long int.  */ long long int atoll (const char *nptr) {   return strtoll (nptr, (char **) NULL, 10); } ===== With that there is no way for get different results from "atolll" and "strtoll". Cheers ! On 18/12/22 10:58, Markus Wichmann wrote: > 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". >> >> ===== >> >> #include >> #include >> >> int main(int argc, char *argv[]) >> { >>     const char *s = "9223372036854775808"; >>     long  long ll = atoll(s); >>     long long ll2 = strtoll (s, (char **) NULL, 10); >>     int imax = 0x7fffffff; >>     printf("%s : %lld : %lld : %d : %d\n",  s, ll, ll2, imax, ll <= imax); >>     return 0; >> } >> >> ===== >> >> Output from "glibc": >> >> ===== >> >> 9223372036854775808 : 9223372036854775807 : 9223372036854775807 : 2147483647 >> : 0 >> >> ===== >> >> Output from "musl": >> >> ===== >> >> 9223372036854775808 : -9223372036854775808 : 9223372036854775807 : >> 2147483647 : 1 >> >> ===== >> >> 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 §7.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