[comp.lang.c] Printf format strings

grodberg@kodak.UUCP (04/04/87)

   In our Sun C compiler, printf("%#07x", 27); prints "0x000001b" (9 characters)
while printf("%#7x", 27); prints "   0x1b" (7 characters). Is this a) common,
b) "correct", c) discussed in the ANSI standard?  My feeling is that the two 
format strings should always generate 7 characters (unless more are necessary 
to represent the number), and losing this battle I would at least hope they 
would both generate 9 characters (either the "0x" is part of the field width 
or it isn't).
-- 
          Jeremy Grodberg

Usenet: ...rochester!kodak!grodberg
Arpa: 	grodberg@kodak or kodak!grodberg@rochester

msb@sq.UUCP (04/07/87)

> In our Sun C compiler, printf("%#07x", 27); prints "0x000001b" (9 characters)
> while printf("%#7x", 27); prints "   0x1b" (7 characters). Is this ...
> discussed in the ANSI standard?

Well, to my eye this section of the *draft proposed* standard is unclear.
The directly relevant bits of 4.9.6.1 are:

#   If the converted value has fewer characters than the field width,
#   it will be padded ... to the field width.  The padding is with spaces
#   unless the field width integer starts with a zero, in which case the
#   padding is with zeros.
	...
#   The flag characters and their meanings are:
	...
#   The result is to be converted to an "alternate form".  ...  For x
#   ... conversion, a nonzero result will have 0x ... prepended to it.

The use of "converted value" together with "converted to an alternate form"
seems to require the first printf to produce "0000x1b", and the second one
to produce what it actually does.  My formal comments to ANSI included a
rewrite of 4.9.6.1 to eliminate a number of other problems with the section,
including some problems with zero-padding, but I must admit I missed this one.

I would guess that the intention was to require "0x0001b" and "   0x1b".
Any semi-official comments?

Mark Brader			"But I do't have a '' key o my termial."
utzoo!sq!msb						   -- Lynn Gold

john@viper.UUCP (04/07/87)

In article <782@kodak.UUCP> grodberg@kodak.UUCP (Jeremy Grodberg) writes:
 >
 >   In our Sun C compiler, printf("%#07x", 27); prints "0x000001b" (9 characters)
 >while printf("%#7x", 27); prints "   0x1b" (7 characters). Is this a) common,
 >b) "correct", c) discussed in the ANSI standard?  My feeling is that the two 
 >format strings should always generate 7 characters (unless more are necessary 
 >to represent the number), and losing this battle I would at least hope they 
 >would both generate 9 characters (either the "0x" is part of the field width 
 >or it isn't).

  No printf() function I've used in the last 5 years supports the
"#" designator.  Since, by your example, I'd guess it's "suppost" to
close-prefix the number by the "0x" designator, my primary suggestion
would be that unless you find this to be in the ANSI standard, that you
stop using it in any code you expect to be able to port anyplace.  You
can take a look at K&R page 145 to see that this is Not included in the
"K&R standard" and thus, is probably not avaiable on a large number of
machines.

I have no idea if "#" is supported by the ANSI standard.  If it is, then
the standard is the place to look (I have no idea which way they'd define
it...)  If not, you'll need to use a different method of getting a right
justified hex constant with-close-preceding "0x" if you expect to be able
to port it to anyplace...

  If I had to, I'd probably use:

     static char cphbuf[20] = "0x";
	.....
     sprintf(&cphbuf[2], "%x", 27);
     printf("%7s", cphbuf);
	.....

  which should work the same way on any system....

--- 
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john

guy@gorodish.UUCP (04/08/87)

>  No printf() function I've used in the last 5 years supports the
>"#" designator.

In other words, you haven't used:

	VAX 4.2BSD
	VAX 4.3BSD
	Any System III or System V release from AT&T
	SunOS
	probably Ultrix-32
	lots of other systems

in the last 5 years.

It's even *documented* in the S3 and S5 manuals.

>Since, by your example, I'd guess it's "suppost" to close-prefix the
>number by the "0x" designator, my primary suggestion would be that
>unless you find this to be in the ANSI standard,

Which he will.