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 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 >