mailing list of musl libc
 help / color / mirror / code / Atom feed
* [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 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).