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=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30386 invoked from network); 13 Oct 2021 14:19:55 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 Oct 2021 14:19:55 -0000 Received: (qmail 11585 invoked by uid 550); 13 Oct 2021 14:19:53 -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 5975 invoked from network); 13 Oct 2021 14:06:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=eteau4a26zmxk2ijau6sgb3me4huyrhc; d=openwall.com.au; t=1634133988; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; bh=JoAFlanLnwicGigpFOnftM1aoGHqV+c7uu8xF1k5E3A=; b=QJFySBCc3uFWylu2N9Bofyea4AOBpPy0A/hLIrxrWUjmDdre1moXVZohNd3wXBRm n6gG8CI/8davDkWUIfuFC5T/pfAE9wwh7aS0fR9wONfkcfSkWgpWlYxHOs9chwzWcpQ VPOA2Jr8x/AnHkDkHen6XDBE6u+IO4irrjTVo+OY= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1634133988; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:Feedback-ID; bh=JoAFlanLnwicGigpFOnftM1aoGHqV+c7uu8xF1k5E3A=; b=VOmbCknriAyyq0wD9soaqRsNteNxioc3ZLh1roSE05oZUFiqv2unyqRgl8OXcKz6 s3NicpDldt9/DG4CkYLQBzfqyYrMR7Z2FrFhksjG8fmcSOWQWGWnMVo1bmnORYQqxMt a9MClcG6VbskWyTwyVCh9WQ2BcbSds+nmwoNd11Y= ARC-Seal:i=1; a=rsa-sha256; d=openwall.com.au; s=20180402; t=1634133987; cv=none; b=pLlHlsSKzFhxp2gCe8QDsWooxAnMlsKcMDnVTmBWE8ZLROhE88lmH0lXzijOULMa6hWUxH6gxjv7FUZPe2EuwoMFJJNzH19Mf9GFv7F+4U7LtXYeFPesViuSCcs/sEgQlcqn4IHyneISS7ol2A5hgK1Wf30Sq6UzF7sv9oLyDvyooYbcpVRxFoQIS9jqnyK+hqhFwkuB54P3mOUfPkTCesPhVEHTGBRvsD71tJP4PGmbc89srQWvyPaOk++wnUkvMoT2uXRdk0TrqbbORnAxOKsudNQLYNN6wQABF9WgCd/vv7He0f2LpTlfUxM8ZF6N4tHxde5ksomWvhOfNFXC7A== ARC-Message-Signature:i=1; a=rsa-sha256; d=openwall.com.au; s=20180402; t=1634133987; c=relaxed/simple; bh=JoAFlanLnwicGigpFOnftM1aoGHqV+c7uu8xF1k5E3A=; h=From:To:Subject; b=Ner5yL5FkYx2O96727PoXbPZwN0ew7/1ShxWkNuBG6KmGXYBq+4ezWrPx7CF9bHNSfxG4rN8ro96mg8Zx3qhJdS5ezLEVEFVRGCMe+B02xvf5SXDL3+uWTM63KcKUn5tsoWa1EuHrT6WiuRONzYXsdgHJp9woVHUILjg6hvEt2kgvGia4w1E/urwjOcJx+v4Cu541I7fiiF6gvol2RYizTpt2lT24OQUKyfvB3eQtNkErZVtZ1X+8zXvUN6L7liSwl2aKAZK0Qgq00GIfM8gv0x7uHsXBP7ylr2WjCARc24ZJkuCcmOxHlz0fpqmKexClUweKvpGyxuzwYAkzo1hMw== ARC-Authentication-Results:i=1; mail.openwall.com.au; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=openwall.com.au; s=20180402; t=1634133987; bh=JoAFlanLnwicGigpFOnftM1aoGHqV+c7uu8xF1k5E3A=; h=From:To:Subject:From; b=uBwJTGsmOEirnHSqutp+hgNS3yVJO3VJRBu56XdI+c7P9Ve4SfnPYPvBLh18PXR6c vjCrmpqwqq7mOb6kOlWPU5GAQVrDMEf6Sab/TgRU0AcvaW3XcwYZbAEnrRV3bgqPM0 fiVYKL0QVUlz6K8WHdohz5ceElCt+MmNTem9sHvR8XNxQmlUL1lXBVQ/fb43km51BM sDBVMJ+GGxTGTynGPckp4ONK7BfoXRMGu/lWVL1DvdMREBhLHdySBTPJQImLBVxI9Y lhZBa3XM3MmbX8BVjEQBHIvppDRZ9J8DenRJVAzD+FtebHN7JbwwASfNAZ0t4Tv2Ly Gib/vfiAtFDQQ== Date: Wed, 13 Oct 2021 14:06:27 +0000 From: "(GalaxyMaster)" To: musl@lists.openwall.com Message-ID: <0100017c79f9d219-86b8d3e7-358a-473c-9736-befc0678d7c7-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Feedback-ID: 1.us-east-1.Br0WpcLm0XzNPYp+t39aA5qSwb/HYCx3zC5wkQY3G2s=:AmazonSES X-SES-Outgoing: 2021.10.13-54.240.8.81 Subject: [musl] strtoll() incompatibility Hello, I am not a true developer, so I don't have the POSIX standard handy, hence could not quickly find whether the observed behaviour is correct or not. I have two systems, one is musl-based and the other is Glibc-based, so every time I stumble upon something I check against Glibc. I know that Glibc developers did quite a few bespoke things, but this particular one made me wonder whether it is a bug in musl. Longs story short, it seems that musl's strto*() set errno when it is unable to find a legitimate number at the begining of the string: === galaxy@musl:~/musl-tests $ cat strtoll.c #include #include #include #include int main() { char *endptr, *str=" .25g "; long long val; errno = 0; val = strtoll(str, &endptr, 10); if (errno != 0) { perror("strtol"); return 1; } if (endptr == str) { fprintf(stderr, "No digits were found\n"); return 1; } printf("strtoll() returned %lld\n", val); if (*endptr != '\0') /* Not necessarily an error... */ printf("Further characters after number: \"%s\"\n", endptr); return 0; } galaxy@musl:~/musl-tests $ gcc -o strtoll strtoll.c galaxy@musl:~/musl-tests $ ./strtoll strtol: Invalid argument galaxy@musl:~/musl-tests $ === The output was from perror(), which indicates that the parsing produced an error. You can actually see how the parsing is done in src/stdlib/strtol.c. At the same time the same code produces the following on a Glibc system: === [galaxy@archlinux musl-tests]$ ./strtoll No digits were found [galaxy@archlinux musl-tests]$ === Which basically tells me that Glibc's strtoll() did not set errno. I don't know what the standard prescribes for this family of functions (I just registered an account at Open Group to download the standard), but from the common sense point of view a string not containing a number for these functions is a valid argument, so responding with EINVAL does not seems to be right. -- (GM)