(first post here )

With printf you can add zeroes to the output by specifying %03d like this:
int x = 123;
printf("%06d\n", x); => will print 000123

How can this be achieved with floats? (if it's possible)

2. You can't, not just using printf's format specifiers anyway. At least not to the left of the decimal point. You can only specify to the right of the decimal point.
Code:
`printf("%.3f", 1.0 );`
Quzah.

3. Code:
```#include <stdio.h>

int main(void)
{
float value = 1.0F;
printf("value = %07.3f\n", value);
return 0;
}

/* my output
value = 001.000
*/```

4. But Dave's response wouldn't work with this number
Code:
```#include <stdio.h>

int main(void)
{
float value = 1000000.0F;
printf("value = %07.3f\n", value);
return 0;
}

/* my output
value = 000.000
*/```
I am sure Dave knew this, I am just pointing it out.

5. That's rather interesting. Run this:
Code:
```#include <stdio.h>

int main( void )
{
printf("%03.3f", 1.1 );
return 0;
}

/*
My output:
1.100
*/```
Dave, change your seven to a three and watch it break. Hell, change it to a 6 and watch it break. I'm not sure what exactly you're trying to say there, because "7" does not give you seven points of precision like it would if it were an integer. The point is, it doesn't work right, and in fact, it isn't even guarinteed that it will work right. Reading the man pages, they only specify that to the right of the decimal point will work.

Quzah.

6. > printf("%03.3f", 1.1 );

The first 3 represents the total field width.

7. Originally Posted by swoopy
> printf("%03.3f", 1.1 );

The first 3 represents the total field width.
Looks like you learn something new every .... well, once in a while anyway. I was thinking it was places left and places right respectively. On an aside, the man pages do say it only works to the right.

An optional precision, in the form of a period
(`.') followed by an optional digit string. If
the digit string is omitted, the precision is taken
as zero. This gives the minimum number of digits
to appear for d, i, o, u, x, and X conversions, the
number of digits to appear after the decimal-point
for e, E, and f conversions,
the maximum number of
significant digits for g and G conversions, or the
string for s conversions.
Here was my misunderstanding.
[/edit]

Quzah.

8. "Undefined" is the word missing from this thread.
0 For d, i, o, u, x, X, e, E, f, g and G conversions, leading zeros
(following any indication of sign or base) are used to pad to the
field width; no space padding is performed. If the 0 and - flags
both appear, the 0 flag will be ignored. For d, i, o, u, x and X
conversions, if a precision is specified, the 0 flag will be
ignored. For other conversions, the behavior is undefined.

9. Yeah. I thought I at least half way knew what I was talking about. I just didn't see it when looking for it a second time...

Quzah.

10. Of course if you have something like:
Code:
`printf("%03.3f\n",1.125);`
Even though it's five wide, at least it doesn't truncate it.

11. Hammer, can you explain that in English.

12. Width specifiers only give you the minimum width. (As with integers. It only gives you a guarinteed minimum width, but if your number is larger, it will not truncate.) So, assuming it was all defined behaviour, the value to the left would be the total guarinteed minimum width, and the value to the right of the decimal point, would be the guarinteed maximum width for everything to the right of the decimal point, truncating anything that would have been longer on the right of the decimal point. But, the entire width would have a minimum guarinteed width based on whatever was left. Assuming defined behaviour.

Quzah.

13. Well, my take on the bolded part in my post is that using the following things in one go is "undefined":
- 0 flag (to give you leading zeros)
- .3 (precision)
- f (to give you a float)

Looking at chrismiceli's post (4th in the thread), they say that the sample code gives output of "000.000", however, when I compile/run it, I get "1000000.000". Assuming chrismiceli did actually compile/run the code to get the result, I guess we're seeing the affects of undefined behaviour. If this is the case, I'd be interested to know what compiler is being used, and what are the results when the following is used in the same program:
printf("value = %07f\n", value);

14. Ok, based on what you both are saying, it would indeed be interesting if chrismiceli were to run:
printf("value = %07f\n", value);

If it prints properly, then we are interpreting the standard correctly, and if you want portable code, you can't specify a precision with %0:
printf("value = %07.3f\n", value);

15. First, let me apologize for being a bit sloppy (less sleep and more diaper changes have been the order of the day for over a week now). I was trying to present a possibility for "How can this be achieved with floats? (if it's possible)". I may have erred, but it did seem to me possible.

I'm a bit tired, but the responses thus far are thought-provoking. One thing that I find of interest is this.
Originally Posted by Hammer
"Undefined" is the word missing from this thread.
0 For d, i, o, u, x, X, e, E, f, g and G conversions, leading zeros (following any indication of sign or base) are used to pad to the field width; no space padding is performed. If the 0 and - flags both appear, the 0 flag will be ignored. For d, i, o, u, x and X conversions, if a precision is specified, the 0 flag will be ignored. For other conversions, the behavior is undefined.
It isn't "d, i, o, u, x and X" or some "other" conversion, it is the f conversion.

I believe C99 and certain other implementations fix some of the shortcomings with snprintf.

Again, I'm a bit tired. But I am interested in more rested follow-ups.