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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 29044 invoked from network); 15 Dec 2021 21:51:58 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Dec 2021 21:51:58 -0000 Received: (qmail 23700 invoked by uid 550); 15 Dec 2021 21:51:56 -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 23649 invoked from network); 15 Dec 2021 21:51:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PEVI0q93q/ER0euhL5FSwt9pDOXp6EYUXjZM2bKl+7k=; b=hq+q1cavYG8GcoAGggUxOMjERWatu0PAnTO1XOAoHv9zpNepxbqdVm+bLWOAXQnWAu beNsBiHS9PpCcBlKRxbY7a/OiqIkYiwWKIww5jXWFXcp0qyVAamycZVzMmmw2Hl/Sjap YuttLwW5yzkmLc50X1ZyYojBMCJuqH1f+ywb5AdCt09JZ+fv8Cl4cSOrqWaj8JNuLE5o BAxRVznZUpil7ZDFNdAnlvFYaWGLVNVUR1qXVQVtT0vaTV3i8hCdjWp/Hsp/Mj8MS1im CjlnmvDg9FiYA5HTNkHtui4H8qFbnROELgSBWSq4RLCq/+AnPmf+IBdnEcEFaVAALYGQ daYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PEVI0q93q/ER0euhL5FSwt9pDOXp6EYUXjZM2bKl+7k=; b=Rv3BBwQCmpcfeKMUJkzph3+UdGYhDY83m9/VrfVcTIOy8q33V397yhWNbOBFQ/oa0M TBWvywLkeQ+kKfW3ubX0I3YSqkrJCu9Pvp3fFkBch5jIDlQTYfPfvBInPSei/AUkjPQ1 DyZHkZsVQU/qWW/kwZZj45dh34QVohjlaMUqOIx+ySKaDo10otYPcArKb9Y8VeI10bkN /zexcSH/Ui/VcLtjduHjJoKpKW6S77YY63IIafy8gOVmh6wyQQ/wjotpetIwcGBi07dW +jaKoH2RPZw5b2Ig0wIdT4PRtQcq/Iho5QG8v4DwcCdPr5rD8L2CfTGU74tGnAEWumht KKKw== X-Gm-Message-State: AOAM532vR0rMdJug8Ljd0thhXqBh422Adqf9r20v3DlQvhNPBu6mKAJD 5dFTTiKHPyoewSqouvNA9TE6njigvf5upwuwKQk= X-Google-Smtp-Source: ABdhPJxcdZGRpHG4Kw8qE3Ex3h21xZbOcWIrZmkKQxuTuIwo0wyK47dZX8bP6GRRMuW5mDzkAQRKL1sVfLcpJIS790g= X-Received: by 2002:a67:ae0f:: with SMTP id x15mr552193vse.57.1639605103754; Wed, 15 Dec 2021 13:51:43 -0800 (PST) MIME-Version: 1.0 References: <20211214160327.GA1494342@port70.net> <20211215190914.233d3021.quinq@fifth.space> <20211215212126.GK7074@brightrain.aerifal.cx> In-Reply-To: From: Andrew Snyder Date: Wed, 15 Dec 2021 16:51:32 -0500 Message-ID: To: enh Cc: Quentin Rameau , musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000c8007d05d3364fb9" Subject: Re: [musl] print does not support variable width plus padding --000000000000c8007d05d3364fb9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I did attempt to create my issue with a simple example and was unable, but I haven=E2=80=99t had time to revisit yet. Once I get time I will try to i= solate. Could be emscripten related I am just not sure at the point we are also using varg version of printf On Wed, Dec 15, 2021 at 4:40 PM enh wrote: > On Wed, Dec 15, 2021 at 1:21 PM Rich Felker wrote: > > > > On Wed, Dec 15, 2021 at 01:37:43PM -0500, Andrew Snyder wrote: > > > That is probably true but I think on accident trying to replicate my > > > original issue which was using the native function > > > > With the program: > > > > #include > > int main(int argc, char **argv) > > { > > printf("%0*i\n", 2, argc); > > } > > > > (written using argc so it can't be collapsed to a constant string at > > compile time) I get output of "01\n" as expected. If you think there's > > a bug in musl for this or related functionality, can you provide a > > minimal C test case? > > > > > On Wed, Dec 15, 2021 at 1:09 PM Quentin Rameau > wrote: > > > > > > > Hi Andrew, > > > > > > > > > Sorry accidentally sent before attaching this > > > > > > > > > > ~# docker run -it --rm alpine /bin/ash > > > > > / # /lib/libc.musl-x86_64.so.1 > > > > > musl libc (x86_64) > > > > > Version 1.2.2 > > > > > Dynamic Program Loader > > > > > Usage: /lib/libc.musl-x86_64.so.1 [options] [--] pathname [args] > > > > > / # printf %0*i 2 1 > > > > > ash: %0*i: invalid format > > > > > > > > This looks like you found a bug in Busybox printf implementation. > > > > FWIW I suspect the problem is that Busybox is not recognizing the 0 > > character as a flag (which it is, in the printf grammar) and thinks > > it's the leading character of a width, making the * specifier for > > width invalid (since a width was already seen). > > yeah, since i was curious whether toybox had an issue too, i tested > this (with bionic and glibc, but _not_ musl) and saw that coreutils > and toybox both produce the correct output, but busybox fails with > "invalid format" for glibc too. > > > Rich > --000000000000c8007d05d3364fb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I did attempt to create my issue with a si= mple example and was unable, but I haven=E2=80=99t had time to revisit yet.= =C2=A0 Once I get time I will try to isolate. Could be emscripten related I= am just not sure at the point we are also using varg version of printf=C2= =A0


On Wed, Dec 1= 5, 2021 at 4:40 PM enh <enh@google.com= > wrote:
On Wed, Dec 15, 2021 at 1:21 PM R= ich Felker <dalias@= libc.org> wrote:
>
> On Wed, Dec 15, 2021 at 01:37:43PM -0500, Andrew Snyder wrote:
> > That is probably true but I think on accident trying to replicate= my
> > original issue which was using the native function
>
> With the program:
>
> #include <stdio.h>
> int main(int argc, char **argv)
> {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0printf("%0*i\n", 2, argc);<= br> > }
>
> (written using argc so it can't be collapsed to a constant string = at
> compile time) I get output of "01\n" as expected. If you thi= nk there's
> a bug in musl for this or related functionality, can you provide a
> minimal C test case?
>
> > On Wed, Dec 15, 2021 at 1:09 PM Quentin Rameau <quinq@fifth.space> wrote: > >
> > > Hi Andrew,
> > >
> > > > Sorry accidentally sent before attaching this
> > > >
> > > > ~# docker run -it --rm alpine /bin/ash
> > > > / # /lib/libc.musl-x86_64.so.1
> > > > musl libc (x86_64)
> > > > Version 1.2.2
> > > > Dynamic Program Loader
> > > > Usage: /lib/libc.musl-x86_64.so.1 [options] [--] pathna= me [args]
> > > > / # printf %0*i 2 1
> > > > ash: %0*i: invalid format
> > >
> > > This looks like you found a bug in Busybox printf implementa= tion.
>
> FWIW I suspect the problem is that Busybox is not recognizing the 0 > character as a flag (which it is, in the printf grammar) and thinks > it's the leading character of a width, making the * specifier for<= br> > width invalid (since a width was already seen).

yeah, since i was curious whether toybox had an issue too, i tested
this (with bionic and glibc, but _not_ musl) and saw that coreutils
and toybox both produce the correct output, but busybox fails with
"invalid format" for glibc too.

> Rich
--000000000000c8007d05d3364fb9--