Re: possible printf error

[Jeff Johnston <jjohnstn at redhat dot com>]

Stephen,

  FWIW, newlib matches glibc on this.  While I can see your point, consider the 
fact that there is already a way to do what you want with a different format 
specifier.  If you have:  printf ("0x%.6x") you get what you are looking for. 
The standard implies that zero will not be prepended by 0x. I don't know the 
background behind this particular design decision.

  Regarding your additional C standard questions:  I suggest the glibc mailing 
list which is monitored by a number of C standard experts who could answer your 
questions in greater detail.

-- Jeff J.

Steven J Abner wrote:
>   First, I am on a system which I believe uses an earlier version of 
> newlibc. I've
> encountered an oddity which may?? be an issue.
>   The use of "printf("%#.6x", 0);" produces "000000". Which, by the IEEE 
> definition of
> the '#' flag states: "For x or X conversion specifiers, a non-zero 
> result shall have
> 0x (or 0X) prefixed to it.",  is correct. However, in a series of hex(s) 
> with a variable
> input rather than an explicit "0", if one is expecting to have an 
> implicit field width
> of 8, ie 0x000030, 0x000100, 0x000000...., or a hex with a 0x prefix 
> when "0" occurs,
> you have to test for 0 and issue "printf("%s", "0x");""printf("%#.6x", 
> 0);".
>   I may have missed the point of a '#' flag, but I thought this 
> incorrect in spite of the
> definition. I can see where "printf("%#.0x", 0);" should drop "0x" but 
> why "%#x"?
>
>   Well, food for thought.
> Thanks,
>      Steve @<tauvan@starpower.net>
>
> PS. Have a couple of others, and would like to know if there is a 
> discussion bb address
> to query, rather than this bug reporting address?