[-- Attachment #1: Type: text/plain, Size: 918 bytes --] I would like to be cc'd on the replies Looks like a bug in the musl printf functionality When using variable width format string and specifying a padding musl fails to format properly. I am using musl indirectly through an emscripten compile of a native library. Consider the following repro steps using alpine docker image. Correct results exist when using ubuntu image # Correct expected ' 1' docker run -it --rm alpine printf %2i 1 # Correct expected ' 1' docker run -it --rm alpine printf %*i 2 1 # Correct expected '01' docker run -it --rm alpine printf %02i 1 # errors, Expected '01' docker run -it --rm alpine printf %0*i 2 1 # Correct expected ' 1' docker run -it --rm ubuntu printf %2i 1 # Correct expected ' 1' docker run -it --rm ubuntu printf %*i 2 1 # Correct expected '01' docker run -it --rm ubuntu printf %02i 1 # Correct expected '01' docker run -it --rm ubuntu printf %0*i 2 1 --Andrew [-- Attachment #2: Type: text/html, Size: 1262 bytes --]
* Andrew Snyder <arsnyder16@gmail.com> [2021-12-14 10:22:42 -0500]:
> I would like to be cc'd on the replies
>
> Looks like a bug in the musl printf functionality
>
> When using variable width format string and specifying a padding musl fails
> to format properly.
>
> I am using musl indirectly through an emscripten compile of a native
> library.
>
> Consider the following repro steps using alpine docker image. Correct
> results exist when using ubuntu image
>
> # Correct expected ' 1'
> docker run -it --rm alpine printf %2i 1
> # Correct expected ' 1'
> docker run -it --rm alpine printf %*i 2 1
> # Correct expected '01'
> docker run -it --rm alpine printf %02i 1
> # errors, Expected '01'
> docker run -it --rm alpine printf %0*i 2 1
i get the expected result on alpine
$ printf %0*i 2 1
01
what do you get?
[-- Attachment #1: Type: text/plain, Size: 1196 bytes --] I get an error from printf i assume that underlying printf function is returning error code. In my native implementation i get incorrect results and really depends on the parameters i didn't dig into too deep to see what the pattern was On Tue, Dec 14, 2021 at 11:03 AM Szabolcs Nagy <nsz@port70.net> wrote: > * Andrew Snyder <arsnyder16@gmail.com> [2021-12-14 10:22:42 -0500]: > > I would like to be cc'd on the replies > > > > Looks like a bug in the musl printf functionality > > > > When using variable width format string and specifying a padding musl > fails > > to format properly. > > > > I am using musl indirectly through an emscripten compile of a native > > library. > > > > Consider the following repro steps using alpine docker image. Correct > > results exist when using ubuntu image > > > > # Correct expected ' 1' > > docker run -it --rm alpine printf %2i 1 > > # Correct expected ' 1' > > docker run -it --rm alpine printf %*i 2 1 > > # Correct expected '01' > > docker run -it --rm alpine printf %02i 1 > > # errors, Expected '01' > > docker run -it --rm alpine printf %0*i 2 1 > > i get the expected result on alpine > > $ printf %0*i 2 1 > 01 > > what do you get? > > [-- Attachment #2: Type: text/html, Size: 1752 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1604 bytes --] 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 On Tue, Dec 14, 2021 at 11:09 AM Andrew Snyder <arsnyder16@gmail.com> wrote: > I get an error from printf i assume that underlying printf function is > returning error code. In my native implementation i get incorrect results > and really depends on the parameters i didn't dig into too deep to see what > the pattern was > > > On Tue, Dec 14, 2021 at 11:03 AM Szabolcs Nagy <nsz@port70.net> wrote: > >> * Andrew Snyder <arsnyder16@gmail.com> [2021-12-14 10:22:42 -0500]: >> > I would like to be cc'd on the replies >> > >> > Looks like a bug in the musl printf functionality >> > >> > When using variable width format string and specifying a padding musl >> fails >> > to format properly. >> > >> > I am using musl indirectly through an emscripten compile of a native >> > library. >> > >> > Consider the following repro steps using alpine docker image. Correct >> > results exist when using ubuntu image >> > >> > # Correct expected ' 1' >> > docker run -it --rm alpine printf %2i 1 >> > # Correct expected ' 1' >> > docker run -it --rm alpine printf %*i 2 1 >> > # Correct expected '01' >> > docker run -it --rm alpine printf %02i 1 >> > # errors, Expected '01' >> > docker run -it --rm alpine printf %0*i 2 1 >> >> i get the expected result on alpine >> >> $ printf %0*i 2 1 >> 01 >> >> what do you get? >> >> [-- Attachment #2: Type: text/html, Size: 2463 bytes --]
On Tue, Dec 14, 2021 at 11:10:23AM -0500, Andrew Snyder wrote: > 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 is the busybox printf(1) command not the printf(3) C function. Rich > On Tue, Dec 14, 2021 at 11:09 AM Andrew Snyder <arsnyder16@gmail.com> wrote: > > > I get an error from printf i assume that underlying printf function is > > returning error code. In my native implementation i get incorrect results > > and really depends on the parameters i didn't dig into too deep to see what > > the pattern was > > > > > > On Tue, Dec 14, 2021 at 11:03 AM Szabolcs Nagy <nsz@port70.net> wrote: > > > >> * Andrew Snyder <arsnyder16@gmail.com> [2021-12-14 10:22:42 -0500]: > >> > I would like to be cc'd on the replies > >> > > >> > Looks like a bug in the musl printf functionality > >> > > >> > When using variable width format string and specifying a padding musl > >> fails > >> > to format properly. > >> > > >> > I am using musl indirectly through an emscripten compile of a native > >> > library. > >> > > >> > Consider the following repro steps using alpine docker image. Correct > >> > results exist when using ubuntu image > >> > > >> > # Correct expected ' 1' > >> > docker run -it --rm alpine printf %2i 1 > >> > # Correct expected ' 1' > >> > docker run -it --rm alpine printf %*i 2 1 > >> > # Correct expected '01' > >> > docker run -it --rm alpine printf %02i 1 > >> > # errors, Expected '01' > >> > docker run -it --rm alpine printf %0*i 2 1 > >> > >> i get the expected result on alpine > >> > >> $ printf %0*i 2 1 > >> 01 > >> > >> what do you get? > >> > >>
[-- Attachment #1: Type: text/plain, Size: 2261 bytes --] To follow up, i am trying to reproduce specifically with some native C code on alpine but am unable to, I am going to switch gears and attempt to isolate when compiled with emscripten, and will log a bug on that end. On Tue, Dec 14, 2021 at 11:50 AM Rich Felker <dalias@libc.org> wrote: > On Tue, Dec 14, 2021 at 11:10:23AM -0500, Andrew Snyder wrote: > > 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 is the busybox printf(1) command not the printf(3) C function. > > Rich > > > > On Tue, Dec 14, 2021 at 11:09 AM Andrew Snyder <arsnyder16@gmail.com> > wrote: > > > > > I get an error from printf i assume that underlying printf function is > > > returning error code. In my native implementation i get incorrect > results > > > and really depends on the parameters i didn't dig into too deep to see > what > > > the pattern was > > > > > > > > > On Tue, Dec 14, 2021 at 11:03 AM Szabolcs Nagy <nsz@port70.net> wrote: > > > > > >> * Andrew Snyder <arsnyder16@gmail.com> [2021-12-14 10:22:42 -0500]: > > >> > I would like to be cc'd on the replies > > >> > > > >> > Looks like a bug in the musl printf functionality > > >> > > > >> > When using variable width format string and specifying a padding > musl > > >> fails > > >> > to format properly. > > >> > > > >> > I am using musl indirectly through an emscripten compile of a native > > >> > library. > > >> > > > >> > Consider the following repro steps using alpine docker image. > Correct > > >> > results exist when using ubuntu image > > >> > > > >> > # Correct expected ' 1' > > >> > docker run -it --rm alpine printf %2i 1 > > >> > # Correct expected ' 1' > > >> > docker run -it --rm alpine printf %*i 2 1 > > >> > # Correct expected '01' > > >> > docker run -it --rm alpine printf %02i 1 > > >> > # errors, Expected '01' > > >> > docker run -it --rm alpine printf %0*i 2 1 > > >> > > >> i get the expected result on alpine > > >> > > >> $ printf %0*i 2 1 > > >> 01 > > >> > > >> what do you get? > > >> > > >> > [-- Attachment #2: Type: text/html, Size: 3398 bytes --]
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.
[-- Attachment #1: Type: text/plain, Size: 606 bytes --] That is probably true but I think on accident trying to replicate my original issue which was using the native function 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] [--] pathname [args] > > / # printf %0*i 2 1 > > ash: %0*i: invalid format > > This looks like you found a bug in Busybox printf implementation. > [-- Attachment #2: Type: text/html, Size: 1012 bytes --]
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) { 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 <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] [--] 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). Rich
On Wed, Dec 15, 2021 at 1:21 PM Rich 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) > { > 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 <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] [--] 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
[-- Attachment #1: Type: text/plain, Size: 2147 bytes --] I did attempt to create my issue with a simple example and was unable, but I haven’t had time to revisit yet. 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 On Wed, Dec 15, 2021 at 4:40 PM enh <enh@google.com> wrote: > On Wed, Dec 15, 2021 at 1:21 PM Rich 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) > > { > > 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 <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] [--] 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 > [-- Attachment #2: Type: text/html, Size: 3041 bytes --]
Rich Felker <dalias@libc.org> wrote:
>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).
Quite so. 0 was missing from the list of valid flag characters.
Moreover only one flag character was being processed so the format
'%0 d', for example, was also considered invalid.
I've submitted a patch to BusyBox.
Ron