* [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).