Re: %#08x formatting of printf

In article <bt3Cf.197471$D47.66412@xxxxxxxxxxxxxxxxxxxxxxxxx>
>> I use %#08x to print unsigned integers in hexadecimal format. ...
>> #08 stands for "pad the number with up to 8 zeroes to complete
>> it to 8 digit number". Is this correct understanding?

Almost. See below ...

Robert Harris <robert.f.harris@xxxxxxxxxxxxxxxx> wrote:
>Bilgehan.Balban@xxxxxxxxx wrote:
>The # is a flag prefixing "0x" to the result
>The 8 is the minimum field width (but some of the field may consist of
>spaces before the "0x"). You really need a precision of 8 and a field
>width of 10 (to include the "0x", so you need: "%#10.8x"

Both of these are correct but incomplete.

As Jordan Abel pointed out elsethread, the "#" flag ("alternate
form") only applies the prefix is the number is nonzero (for both
octal and hex conversions, in fact). ("Alternate form" has different
meanings for floating-point formats as well.)

The "0" in "08" is also a flag, meaning "pad with zeros instead of
blanks" (for numeric conversions -- the effect is undefined for
conversions like %s). To include a zero flag, it must (obviously)
appear before a numeric field width: "%09d" means "pad with zeros,
9 wide, decimal" but "%90d" means "pad with blanks, 90 wide,
decimal". The zero flag only applies for right-justified fields;
if you specify both the "-" flag and the "0" flag, the "0" flag is
ignored: "%-9d" and "%-09d" mean the same thing (as does "%0-9d").

Using a precision, as in Robert Harris' example above, is roughly
equivalent to specifying the zero flag. But it is not exactly the
same. For instance:

printf("5.2d: >%5.2d<\n", 5);
printf("05d: >%05d<\n", 5);

prints lines with "> 05<" and ">00005<" respectively.

Using "%#10.8x" will do the Right Thing for all nonzero numbers:

printf("*%#10.8x*\n", 0x4321); /* prints *0x00004321* */

but for 0 you get:

printf("*%#10.8x*\n", 0); /* prints * 00000000* */

Note that the 0x has disappeared (as required for "%#x" format),
so 10.8 -- a field width of 10, with a precision of 8 -- now pads
with blanks.

You could leave out the field width ("%#.8x"), but then nonzero
numbers will occupy 10 character fields (8 digits plus the leading
0x) while zero will use 8 character (8 digits, no leading 0x).
You could even write "%#010.8x" and hope for zero padding when
the 0x is omitted, but this seems ... wrong. :-)

The two "best" alternatives are likely "0x%.8x" or "0x%08x",
which will do exactly the same thing.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
.

Relevant Pages

  • Re: Best Quote on Computer Architecture?
    ... (Perfection is achieved, not when there is nothing more to add, ... left in the carry flag. ... Updates the combined buffer pointer, ... I think you meant the zero flag. ...
    (comp.arch)
  • Re: Best Quote on Computer Architecture?
    ... (Perfection is achieved, not when there is nothing more to add, ... An outgoing carry will be left in the carry flag. ... On a dual-issue, in-order cpu like the original Pentium, this code will pair perfectly, all address updates will happen at least one cycle before they are needed, avoiding any AGI stalls, and the special-casing of carry vs zero flag handling in INC/DEC allows all carry wraparound to happen transparently. ... I.e. this is code that in some ways is absolutely perfect: There is absolutely nothing to subtract, and all the parts mesh together. ...
    (comp.arch)
  • Re: YS - How to hack (ZX) - an assembler issue
    ... > It depends on what precedes the DEC in the code. ... A NOP has no effect on ... will reset the Zero flag (unless the operands are already ...
    (comp.sys.sinclair)