* [musl] print does not support variable width plus padding @ 2021-12-14 15:22 Andrew Snyder 2021-12-14 16:03 ` Szabolcs Nagy 0 siblings, 1 reply; 12+ messages in thread From: Andrew Snyder @ 2021-12-14 15:22 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] print does not support variable width plus padding 2021-12-14 15:22 [musl] print does not support variable width plus padding Andrew Snyder @ 2021-12-14 16:03 ` Szabolcs Nagy 2021-12-14 16:09 ` Andrew Snyder 0 siblings, 1 reply; 12+ messages in thread From: Szabolcs Nagy @ 2021-12-14 16:03 UTC (permalink / raw) To: Andrew Snyder; +Cc: musl * 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] print does not support variable width plus padding 2021-12-14 16:03 ` Szabolcs Nagy @ 2021-12-14 16:09 ` Andrew Snyder 2021-12-14 16:10 ` Andrew Snyder 0 siblings, 1 reply; 12+ messages in thread From: Andrew Snyder @ 2021-12-14 16:09 UTC (permalink / raw) To: Andrew Snyder, musl [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] print does not support variable width plus padding 2021-12-14 16:09 ` Andrew Snyder @ 2021-12-14 16:10 ` Andrew Snyder 2021-12-14 16:50 ` Rich Felker 2021-12-15 18:09 ` Quentin Rameau 0 siblings, 2 replies; 12+ messages in thread From: Andrew Snyder @ 2021-12-14 16:10 UTC (permalink / raw) To: Andrew Snyder, musl [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] print does not support variable width plus padding 2021-12-14 16:10 ` Andrew Snyder @ 2021-12-14 16:50 ` Rich Felker 2021-12-14 17:05 ` Andrew Snyder 2021-12-15 18:09 ` Quentin Rameau 1 sibling, 1 reply; 12+ messages in thread From: Rich Felker @ 2021-12-14 16:50 UTC (permalink / raw) To: Andrew Snyder; +Cc: musl 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? > >> > >> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] print does not support variable width plus padding 2021-12-14 16:50 ` Rich Felker @ 2021-12-14 17:05 ` Andrew Snyder 0 siblings, 0 replies; 12+ messages in thread From: Andrew Snyder @ 2021-12-14 17:05 UTC (permalink / raw) To: Rich Felker; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] print does not support variable width plus padding 2021-12-14 16:10 ` Andrew Snyder 2021-12-14 16:50 ` Rich Felker @ 2021-12-15 18:09 ` Quentin Rameau 2021-12-15 18:37 ` Andrew Snyder 1 sibling, 1 reply; 12+ messages in thread From: Quentin Rameau @ 2021-12-15 18:09 UTC (permalink / raw) To: musl; +Cc: Andrew Snyder 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] print does not support variable width plus padding 2021-12-15 18:09 ` Quentin Rameau @ 2021-12-15 18:37 ` Andrew Snyder 2021-12-15 21:21 ` Rich Felker 0 siblings, 1 reply; 12+ messages in thread From: Andrew Snyder @ 2021-12-15 18:37 UTC (permalink / raw) To: Quentin Rameau; +Cc: musl [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] print does not support variable width plus padding 2021-12-15 18:37 ` Andrew Snyder @ 2021-12-15 21:21 ` Rich Felker 2021-12-15 21:40 ` enh 2021-12-16 11:22 ` Ron Yorston 0 siblings, 2 replies; 12+ messages in thread From: Rich Felker @ 2021-12-15 21:21 UTC (permalink / raw) To: Andrew Snyder; +Cc: Quentin Rameau, musl 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] print does not support variable width plus padding 2021-12-15 21:21 ` Rich Felker @ 2021-12-15 21:40 ` enh 2021-12-15 21:51 ` Andrew Snyder 2021-12-16 11:22 ` Ron Yorston 1 sibling, 1 reply; 12+ messages in thread From: enh @ 2021-12-15 21:40 UTC (permalink / raw) To: musl; +Cc: Andrew Snyder, Quentin Rameau 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] print does not support variable width plus padding 2021-12-15 21:40 ` enh @ 2021-12-15 21:51 ` Andrew Snyder 0 siblings, 0 replies; 12+ messages in thread From: Andrew Snyder @ 2021-12-15 21:51 UTC (permalink / raw) To: enh; +Cc: Quentin Rameau, musl [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] print does not support variable width plus padding 2021-12-15 21:21 ` Rich Felker 2021-12-15 21:40 ` enh @ 2021-12-16 11:22 ` Ron Yorston 1 sibling, 0 replies; 12+ messages in thread From: Ron Yorston @ 2021-12-16 11:22 UTC (permalink / raw) To: musl, arsnyder16; +Cc: quinq, musl 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-12-16 11:22 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-14 15:22 [musl] print does not support variable width plus padding Andrew Snyder 2021-12-14 16:03 ` Szabolcs Nagy 2021-12-14 16:09 ` Andrew Snyder 2021-12-14 16:10 ` Andrew Snyder 2021-12-14 16:50 ` Rich Felker 2021-12-14 17:05 ` Andrew Snyder 2021-12-15 18:09 ` Quentin Rameau 2021-12-15 18:37 ` Andrew Snyder 2021-12-15 21:21 ` Rich Felker 2021-12-15 21:40 ` enh 2021-12-15 21:51 ` Andrew Snyder 2021-12-16 11:22 ` Ron Yorston
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).