From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10840 Path: news.gmane.org!.POSTED!not-for-mail From: Ryan Prichard Newsgroups: gmane.linux.lib.musl.general Subject: Edge case: strtol with base==1 Date: Sun, 1 Jan 2017 04:45:19 -0600 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114747e4a2b08d054506215d X-Trace: blaine.gmane.org 1483267544 15419 195.159.176.226 (1 Jan 2017 10:45:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 1 Jan 2017 10:45:44 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10853-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jan 01 11:45:38 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cNddt-0002Rp-EZ for gllmg-musl@m.gmane.org; Sun, 01 Jan 2017 11:45:33 +0100 Original-Received: (qmail 15844 invoked by uid 550); 1 Jan 2017 10:45:34 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 15807 invoked from network); 1 Jan 2017 10:45:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=KSDTw7Ek6NgpXtRzK5CthuRZ6QhR8KoOXms9kPZWg2A=; b=ChCzePQQlkp7eE7bs1TLp6v9bKn3XmvXKrurnC9VU5FxjrGim64ft9JnqqwFrEWeWx K34oD+LAKHaqDKclC1syPy/q9Ajv0h/Pcv5lBYRVP73/trfbIqiQlYi++01/gnMPWGli tb67699C77obkbQ2Ej4BolZsrJJvhJwxnK2tUhWN7B7Mx23xpGTjkMwkOBIOVRJ9CDRJ 6IpF60fMn4E8hIqdljrIKl+5hAGgk6us5qSGl9v3oxXLm/w3y+pxdftqQgLlyru6sLrQ +agMStK0kW6v4kAIb1g+TOvyV9SbFm3eq70uuzyt4BDXX3vOQ+igW8zZ+75oT5/3CjkN v8CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KSDTw7Ek6NgpXtRzK5CthuRZ6QhR8KoOXms9kPZWg2A=; b=CVa7Bsrc0sgQZU1KNDIPyXypn3mtI6+yhD0KpwABzIMyipGlfAvkqjfTsWsWlW8MSc 0x6VuOUqGUxyhNlwDIM4bBfr76AfUCQz0AeCUy8Yp7hJ5R4fY5zqJVKSeP10AiVVL+aJ C4cDh9+Zmo5RkyKKCxVtdcrWDOI1sXWck4ZJHZuQ9xFiKH/PAFm9W8WJSM2jdxYu9n+T UfLypDLe1NBJZsb9lj/qjSuZeWh7pSTK2QcCiEAXaLTek7qKNdK37ofvMD6lJQAMabYE qs/7aE3yagoDFHRKolxamU+WvYney6X7uvyD7XLrm2519xXhwveWmhAu6ZN38dReVPzo BHCg== X-Gm-Message-State: AIkVDXLBTKeWFQKA13SoljHr598aRKyP5MpnvgW4ngWoa1bJtgh7dShU6mFFkFTCdh8iOUwju9gY4mShRfQ8WA== X-Received: by 10.36.123.23 with SMTP id q23mr40768136itc.12.1483267519982; Sun, 01 Jan 2017 02:45:19 -0800 (PST) Xref: news.gmane.org gmane.linux.lib.musl.general:10840 Archived-At: --001a114747e4a2b08d054506215d Content-Type: text/plain; charset=UTF-8 Hi, I noticed that musl's strtol function allows a base of 1 by parsing strings of only zeros. With all other bases less than 0 or greater than 36, strtol fails and sets errno to EINVAL. Is this an oversight? Not that it especially *matters*, but my guess is that the behavior isn't POSIX conforming: - POSIX defines valid "subject sequences" for bases of 0 and 2-36. - "In other than the C or POSIX locale, additional locale-specific subject sequence forms may be accepted." In the C locale, musl is accepting a subject sequence of all zeroes, which POSIX doesn't define for a base of 1. http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html e.g.: #include #include #include #include int main() { errno = 0; char *endptr = "unset"; long val = strtol(" 0001", &endptr, 1); printf("errno=[%s], val=%ld, endptr=[%s]\n", strerror(errno), val, endptr ? endptr : "(null)"); return 0; } $ gcc test.c && ./a.out errno=[Invalid argument], val=0, endptr=[unset] $ musl-gcc test.c && ./a.out errno=[No error information], val=0, endptr=[1] -Ryan --001a114747e4a2b08d054506215d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I noticed that musl's strtol fu= nction allows a base of 1 by parsing strings of only zeros.=C2=A0 With all = other bases less than 0 or greater than 36, strtol fails and sets errno to = EINVAL.

Is this an oversight?

=
Not that it especially *matters*, but my guess is that the behavior is= n't POSIX conforming:
=C2=A0- POSIX defines valid "subje= ct sequences" for bases of 0 and 2-36.
=C2=A0- "In othe= r than the C or POSIX locale, additional locale-specific subject sequence f= orms may be accepted."

In the C locale, musl = is accepting a subject sequence of all zeroes, which POSIX doesn't defi= ne for a base of 1.


=
e.g.:

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#in= clude <string.h>

int main() {
=C2= =A0 =C2=A0 errno =3D 0;
=C2=A0 =C2=A0 char *endptr =3D "unse= t";
=C2=A0 =C2=A0 long val =3D strtol(" =C2=A00001"= ;, &endptr, 1);
=C2=A0 =C2=A0 printf("errno=3D[%s], val= =3D%ld, endptr=3D[%s]\n",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 strerr= or(errno), val, endptr ? endptr : "(null)");
=C2=A0 =C2= =A0 return 0;
}

$ gcc test.c = && ./a.out
errno=3D[Invalid argument], val=3D0, endptr=3D= [unset]

$ musl-gcc test.c && ./a.out
=
errno=3D[No error information], val=3D0, endptr=3D[1]
=
-Ryan

--001a114747e4a2b08d054506215d--