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 698 invoked from network); 27 Oct 2023 02:27:40 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 27 Oct 2023 02:27:40 -0000 Received: (qmail 22355 invoked by uid 550); 27 Oct 2023 02:27:37 -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 18428 invoked from network); 27 Oct 2023 01:41:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698370859; x=1698975659; darn=lists.openwall.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6SFCiK7jU2VLROyH+yU6SjmpD++3Z29Gdl/x9qw4LzQ=; b=SL4pH12EsQ1X65PYXjAxv1BwGaXMBaf9wxW2edc6gdax9+oBot24TYWPXCXOs9CfpF BZowBIn6fD/6xIMgKzwx5oMfceg2t8crSNHetTLSNKnVbPts2h2L1F5tMKWq19ZEyRel m9XQWvzoMnSgbYUO8D6KgZU2xbYoO7OINRaORGrS01AvJb9V1ufSnGfEH5GHZWsJX5aZ x8YiuLv005d7FnSyLaSyXy1PQ4mILJXp4tWd/uoiJlc7fo9NZ4wTX0l2u5ABLeUr7uDR rzcG5jzJFtBaRxxQmdnmcguLtGdN/9u9bCf6jqlLO7qKAKxBgmsEoW5ie/mtmVwNCa/e Ot7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698370859; x=1698975659; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6SFCiK7jU2VLROyH+yU6SjmpD++3Z29Gdl/x9qw4LzQ=; b=R7WRRuxWATwRnTRUcq0X0TGek2zUinM3OuPdiJkIoq1rYCPd1wCF7oQjzmo3zGWPxM m6Uk0RAm5xHycAhPIKVcGIVryfd3Y+5GWIhcGhxFvQdncesbBfE42NzprhPd7H2UIw4l H9rfeMlT8kFH8S8BVumhAQSkMm6O+hN71BNwZvLka4q6pyAgs3vlrZAJOJK/WDIcGbXu m9ohsTtJ7IiYOIMQmB7sWMOaCDrlzEmEjtwAgxxvggFBU/UIs3bJUFNyipwtQwe4wM/a jZpgja+1W9vp9XuUwSerDTpvnrsEv9/zAULNXv4ZNTdqjXqA//NgRD/zK3fSD8zI/tx0 bczA== X-Gm-Message-State: AOJu0Yw7D+KVQDJge5vSCbhRlvlksonr7pgMQXBKTHMy8Q4b9omn1bMp ElgoZHrdO1rKI1KojNB5bfJxYQm8gF0EaNsRSIjo2yol4foX8n1/Qbg= X-Google-Smtp-Source: AGHT+IFe4EceZlPWr4TR60DkGAR9dyc/3NB1v2Drl5vpUZM3ykmWTYjynaWMT8D5NotsgAfb5ZBgEaDBcRYSAQ44/No= X-Received: by 2002:a17:907:74d:b0:9c6:9342:1459 with SMTP id xc13-20020a170907074d00b009c693421459mr872624ejb.20.1698370858617; Thu, 26 Oct 2023 18:40:58 -0700 (PDT) MIME-Version: 1.0 References: <20231027013834.GQ4163@brightrain.aerifal.cx> In-Reply-To: <20231027013834.GQ4163@brightrain.aerifal.cx> From: Peter Kasting Date: Thu, 26 Oct 2023 18:40:45 -0700 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000ba4c680608a8c795" Subject: Re: [musl] vfprintf(..., "%lc", (wint_t)0) fails to output a \0 --000000000000ba4c680608a8c795 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sounds good. Thanks! PK On Thu, Oct 26, 2023, 6:38=E2=80=AFPM Rich Felker wrote: > On Thu, Oct 26, 2023 at 05:56:09PM -0700, Peter Kasting wrote: > > (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 =3D sprintf(buf, "%lc", (wint_t)0); > > assert(len > 0); > > assert(buf[0] =3D=3D 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 t= he > > code above, so this is speculation. I reproduced this bug indirectly vi= a > a > > Linux Alpine test environment here at Google while trying to make chang= es > > 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. Her= e > > 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 = =3D=3D > > wc[0] =3D=3D 0, so wctomb() is never called. > > > > The C99 spec here arguably allows this behavior, but I believe its inte= nt > > is to specify the behavior glibc's implementation exhibits (where a 0 i= s > > written). Section 7.19.6.1.8 says regarding %lc, "...the wint_t argumen= t > 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 eleme= nt > > of an array of wchar_t type. Wide characters from the array are convert= ed > > to multibyte characters...up to and including a terminating null wide > > character. The resulting multibyte characters are written up to (but no= t > > including) the terminating null character (byte)." One could argue that > the > > first (zero) element in the array, being a 0, is "a terminating null wi= de > > 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 w= as > > 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. > > As I understand it, this was raised with the committee and since musl > was found to be the only conforming implementation, they've opted to > change the spec to what you expect was the intent. So we'll be > changing this at some point to follow. > > Rich > --000000000000ba4c680608a8c795 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sounds good. Thanks!

PK

On Thu, Oct 26, 2023, 6:38=E2=80=AFPM Rich Felker <dalias@libc.org> wrote:
On Thu, Oct 26, 2023 at 05:56:09PM -0700, Peter= Kasting wrote:
> (I'm not subscribed here, please CC me on any responses.)
>
> I believe* the following program will fail on musl:
>
> #include <assert.h>
> #include <stdio.h>
> #include <string.h>
> #include <wchar.h>
>
> int main() {
>=C2=A0 =C2=A0char buf[16];
>=C2=A0 =C2=A0memset(buf, 1, 16);
>=C2=A0 =C2=A0int len =3D sprintf(buf, "%lc", (wint_t)0);
>=C2=A0 =C2=A0assert(len > 0);
>=C2=A0 =C2=A0assert(buf[0] =3D=3D 0);
>=C2=A0 =C2=A0return 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 t= est the
> code above, so this is speculation. I reproduced this bug indirectly v= ia a
> Linux Alpine test environment here at Google while trying to make chan= ges
> to Abseil's string-handling implementation.
>
> >From code inspection, the problem occurs at
> https://git.musl-l= ibc.org/cgit/musl/tree/src/stdio/vfprintf.c#n611. Here
> the loop guard tests `*ws` to ensure it stops on null terminators. How= ever,
> when we fall through from handling this input case (of "%lc"= , 0), *ws =3D=3D
> wc[0] =3D=3D 0, so wctomb() is never called.
>
> The C99 spec here arguably allows this behavior, but I believe its int= ent
> 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 a= rgument is
> converted as if by an ls conversion specification with no precision an= d an
> argument that points to the initial element of a two-element array of<= br> > wchar_t, the first element containing the wint_t argument to the lc > conversion specification and the second a null wide character." A= nd
> 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 conver= ted
> to multibyte characters...up to and including a terminating null wide<= br> > character. The resulting multibyte characters are written up to (but n= ot
> including) the terminating null character (byte)." One could argu= e that the
> first (zero) element in the array, being a 0, is "a terminating n= ull 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 s= econd
> array element always treated as "the null terminator". I don= 't know if
> there is further clarifying language/discussion in some mailing list o= r
> archives somewhere.

As I understand it, this was raised with the committee and since musl
was found to be the only conforming implementation, they've opted to change the spec to what you expect was the intent. So we'll be
changing this at some point to follow.

Rich
--000000000000ba4c680608a8c795--