Steve
2014-04-15 18:13:13 UTC
Hello,
I have:
printf("HARDCODED:that is 09.2f: <%09.2f>\n", 123.45);
I would expect this to result in "00123.45" but instead I get " 123.45".
Per information I've been able to gather, including from OW's documentation,
it appears that there MAY be a non-standard implementation here:
ISO/IEC says
For d, i, o, u, x, X, a, A, e, E, f, F, g, and G conversions, leading zeros
(following any indication of sign or base) are used to pad to the field
width rather
than performing space padding, except when converting an infinity or NaN. If
the
0 and - flags both appear, the 0 flag is ignored. For d, i, o, u, x, and X
conversions, if a precision is specified, the 0 flag is ignored. For other
conversions, the behavior is undefined.
OW says:
http://www.openwatcom.org/ftp/manuals/current/clib.pdf
If no field width is specified, or if the value that is given is less than
the number of characters in the converted value (subject to any precision
value), a field of sufficient width to contain the converted value is used.
"If the converted value has fewer characters than are specified by the field
width, the value is padded on the left (or right, subject to the
left-justification flag) with spaces or zero characters ("0").
" If the field width begins with "0" and no precision is specified, the
value is padded with zeros; otherwise the value is padded with spaces.
"If the field width is "*", a value of type int from the argument list is
used (before a precision argument or a conversion argument) as the minimum
field width. A negative field width value is interpreted as a
left-justification flag, followed by a positive field width."
To me this seems inconsisent.
Btw, FWIW, I am still on Watcom 11 - I know it's not supported - but went
ahead with this post since the OW Manual seems to confirm this odd behavior.
Thanks,
Steve
I have:
printf("HARDCODED:that is 09.2f: <%09.2f>\n", 123.45);
I would expect this to result in "00123.45" but instead I get " 123.45".
Per information I've been able to gather, including from OW's documentation,
it appears that there MAY be a non-standard implementation here:
ISO/IEC says
For d, i, o, u, x, X, a, A, e, E, f, F, g, and G conversions, leading zeros
(following any indication of sign or base) are used to pad to the field
width rather
than performing space padding, except when converting an infinity or NaN. If
the
0 and - flags both appear, the 0 flag is ignored. For d, i, o, u, x, and X
conversions, if a precision is specified, the 0 flag is ignored. For other
conversions, the behavior is undefined.
OW says:
http://www.openwatcom.org/ftp/manuals/current/clib.pdf
If no field width is specified, or if the value that is given is less than
the number of characters in the converted value (subject to any precision
value), a field of sufficient width to contain the converted value is used.
"If the converted value has fewer characters than are specified by the field
width, the value is padded on the left (or right, subject to the
left-justification flag) with spaces or zero characters ("0").
" If the field width begins with "0" and no precision is specified, the
value is padded with zeros; otherwise the value is padded with spaces.
"If the field width is "*", a value of type int from the argument list is
used (before a precision argument or a conversion argument) as the minimum
field width. A negative field width value is interpreted as a
left-justification flag, followed by a positive field width."
To me this seems inconsisent.
Btw, FWIW, I am still on Watcom 11 - I know it's not supported - but went
ahead with this post since the OW Manual seems to confirm this odd behavior.
Thanks,
Steve