Zero padding disabled when precision specified, spaces padded instead

[Iangitpers]

An issue I've noticed:
uint c=29;
printf("%03.u", c);
Output: " 29"
Expected: "029"

In v5.2.0 around line 961:

       // ignore '0' flag when precision is given
        if ((flags & FLAGS_PRECISION)) {
          flags &= ~FLAGS_ZEROPAD;
        }

A hack:

       // ignore '0' flag when precision is given
        //HACK: we want the leading 0s with precision....
        if ((flags & FLAGS_PRECISION) && (*format != 'u')) {
          flags &= ~FLAGS_ZEROPAD;
        }

Maybe there is a logical reason for this, or maybe the precision handling code isn't aware of the padding type it should be doing?

Thank you for maintaining this. I just found the updated fork. I've been using v4 for years.

[eyalroz]

First, thank you for the kind words.

Second - I'll assume you meant unsigned int rather than uint which is not standard C.

Now... if we build this:

#include <stdio.h>
int main() {
    unsigned c=29;
    printf("%03.u\n", c);
    return 0;
}

against glibc 2.31-13, we get:

 29

with no 0. Are you claiming that glibc's implementation contradicts the standard?

To my knowledge, when you explicitly specify the precision (which in your case I believe you are - no-number is interpreted as 0 precision) - 0-instead-of-space padding is ignored. This is also how things are described on this page. If you believe that's a mistake, please refer me to the relevant places in the official standard.

[Iangitpers]

Thank you for your prompt reply. That seems like a logical reason. Apologies for the misfiled report. I see there may be an alternative way to get my desired output.

[eyalroz]

Apologies for the misfiled report.

No problem whatsoever. But it always helps to check what glibc's printf() does first.

I see there may be an alternative way to get my desired output.

What's wrong with printf("%03u")? That gives you 029.

[Iangitpers]

You're absolutely correct. I was totally ignorant that this library so closely tracked an official reference standard. I'm really sorry for the bother. Thank you again for maintaining a current fork.

[eyalroz]

Well, the best ways to thank me are:

1. If you can spare the time - work on issue Proper handling of denormals other than +/- 0.0 #72 and submit a PR.
2. If you have experience in minimizing object code - offer ideas about ways to decrease the library's size without sacrificing functionality.
3. Try to get the library officially adopted in your project/organization/workplace, and have it inform me about this fact so I can brag in the README.md
4. Tell others about the library.