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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HTML_MESSAGE,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 31109 invoked from network); 27 Oct 2023 01:37:29 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 27 Oct 2023 01:37:29 -0000 Received: (qmail 13432 invoked by uid 550); 27 Oct 2023 01:37:25 -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 13871 invoked from network); 27 Oct 2023 00:56:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698368184; x=1698972984; darn=lists.openwall.com; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=thlxIoTHWHkfN0Xyi/44yY6Eoy9Q/IjAtAEMOIE9SKk=; b=uphlijH0kjv3Bcfnyw+nhBaO4drk3GP4FuATW0tqQipjNKp3dfKujTYb4jrE28PLp2 UK2UsJaUh5pQpmXoncAAyH1xzQdYmxl3mpISsOqziYADFw4CDw72lg9xUuC7jazrEN7J 5w6/Jg4Wpdw9Zp23r+hE3kQ/kbCjbVsj3+6vKbEdfmuR8NB132XThZFE3Mx8avW+2NWO vooP3riZFyXFBGfAhTplLAkKq+5WmyG0xz16mUAVCequ1sD4qUHCsdeUaLMrn0KOKZ4v IwzBbHLF1DKuV7gruf5P74EYH0uF7hbvrDGvlbBq1rgN4qeGABy4E4C2Q4qemGM/SD4Y eQoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698368184; x=1698972984; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=thlxIoTHWHkfN0Xyi/44yY6Eoy9Q/IjAtAEMOIE9SKk=; b=Eksm/PiRV2MjGzjz4BgcYxwq7U0UTX//HPo0LvV38CjFU1omv4u1M7UiuHZZUXjT5n hKR3CcxuQqmdnvn6vhkPDmBRBx3AuPg8UJV+sXz3yxbCdIhbzCjj+wkB34cWZsIwRGaL 28ATu7KPlGzf+IuEf2EQrZ/g9XsLDcPrJwgfmudVHPt33YEiuVQOCIv/MQxtE84DdOJg 7D3dN71+5ss45Q2usYAcONskXjlCCVopXdMJIDvBaAXgcueBVlQhAa8bmh+/U/XuYPtp qX1YmFnP7nd4GhG7yV7WIGeEQTRmIZ71CRbR26YAnoOTvZdX4XSpXEP5IiFWHFzjSe/F 8OkQ== X-Gm-Message-State: AOJu0YxDqRzbkkAKSAcUzSoG9CHZMLMHV4AIurlBpvsfInymZ0XyLdGm cXyKDjZfXc+Es2vMcd54ZU7HVwkdEVgxKCWCST81Xx6V6rm8u7iz1FW0tA== X-Google-Smtp-Source: AGHT+IGnYWP/mmLQUbaRXyQ/721DddvXedQ4KNUiYSpfVFgXhr8bUExX1vYnLYPMZ3cpfOogR2gPALg94wZptfLSmmc= X-Received: by 2002:a17:907:2d09:b0:9c3:a3f2:4cec with SMTP id gs9-20020a1709072d0900b009c3a3f24cecmr1005357ejc.0.1698368183225; Thu, 26 Oct 2023 17:56:23 -0700 (PDT) MIME-Version: 1.0 From: Peter Kasting Date: Thu, 26 Oct 2023 17:56:09 -0700 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="00000000000042f1810608a82805" Subject: [musl] vfprintf(..., "%lc", (wint_t)0) fails to output a \0 --00000000000042f1810608a82805 Content-Type: text/plain; charset="UTF-8" (I'm not subscribed here, please CC me on any responses.) I believe* the following program will fail on musl: #include #include #include #include int main() { char buf[16]; memset(buf, 1, 16); int len = sprintf(buf, "%lc", (wint_t)0); assert(len > 0); assert(buf[0] == 0); return 0; } This should write a \0 to the buffer, but will write nothing. *I don't have direct access to a musl environment to compile and test the code above, so this is speculation. I reproduced this bug indirectly via a Linux Alpine test environment here at Google while trying to make changes to Abseil's string-handling implementation. >From code inspection, the problem occurs at https://git.musl-libc.org/cgit/musl/tree/src/stdio/vfprintf.c#n611. Here the loop guard tests `*ws` to ensure it stops on null terminators. However, when we fall through from handling this input case (of "%lc", 0), *ws == wc[0] == 0, so wctomb() is never called. The C99 spec here arguably allows this behavior, but I believe its intent is to specify the behavior glibc's implementation exhibits (where a 0 is written). Section 7.19.6.1.8 says regarding %lc, "...the wint_t argument is converted as if by an ls conversion specification with no precision and an argument that points to the initial element of a two-element array of wchar_t, the first element containing the wint_t argument to the lc conversion specification and the second a null wide character." And regarding %ls, "...the argument shall be a pointer to the initial element of an array of wchar_t type. Wide characters from the array are converted to multibyte characters...up to and including a terminating null wide character. The resulting multibyte characters are written up to (but not including) the terminating null character (byte)." One could argue that the first (zero) element in the array, being a 0, is "a terminating null wide character" that should be converted to a multibyte character, but subsequently not written (since the conversion will result in solely a terminating null character). But it seems like the intent of the spec was to say that a %lc argument is always converted and written, with the second array element always treated as "the null terminator". I don't know if there is further clarifying language/discussion in some mailing list or archives somewhere. PK --00000000000042f1810608a82805 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(I'm not subscribed here, please CC me on any response= s.)

I believe* the following program will fail on musl:<= /div>

#include <assert.h>
#include <s= tdio.h>
#include <string.h>
#include <wchar= .h>

int main() {
=C2=A0 char buf[16];=
=C2=A0 memset(buf, 1, 16);
=C2=A0 int len =3D sprintf(= buf, "%lc", (wint_t)0);
=C2=A0 assert(len > 0);
=C2=A0 assert(buf[0] =3D=3D 0);
=C2=A0 return 0;
= }

This should write a \0 to the buffer, but will w= rite nothing.

*I don't have direct access to a= musl environment to compile and test the code above, so this is speculatio= n. I reproduced this bug indirectly via a Linux Alpine test environment her= e at Google while trying to make changes to Abseil's=C2=A0string-handli= ng implementation.

From code inspection, the probl= em occurs at=C2=A0https://git.musl-libc.org/cgit/musl/tree/src/stdio/vf= printf.c#n611. Here the loop guard tests `*ws` to ensure it stops on nu= ll terminators. However, when we fall through from handling this input case= (of "%lc", 0), *ws =3D=3D wc[0] =3D=3D 0, so wctomb() is never c= alled.

The C99 spec here arguably allows this beha= vior, but I believe its intent is to specify the behavior glibc's imple= mentation exhibits (where a 0 is written). Section 7.19.6.1.8 says regardin= g %lc, "...the wint_t argument is converted as if by an ls conversion = specification with no precision and an argument that points to the initial = element of a two-element array of wchar_t, the first element containing the= wint_t argument to the lc conversion specification and the second a null w= ide character." And regarding %ls, "...the argument shall be a po= inter to the initial element of an array of wchar_t type. Wide characters f= rom the array are converted to multibyte characters...up to and including a= terminating null wide character. The resulting multibyte characters are wr= itten up to (but not including) the terminating null character (byte)."= ; One could argue that the first (zero) element in the array, being a 0, is= "a terminating null wide character" that should be converted to = a multibyte character, but subsequently not written (since the conversion w= ill result in solely a terminating null character). But it seems like the i= ntent of the spec was to say that a %lc argument is always converted and wr= itten, with the second array element always treated as "the null termi= nator". I don't know if there is further clarifying language/discu= ssion in some mailing list or archives somewhere.

= PK
--00000000000042f1810608a82805--