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@rochestermsb@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.