Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!utfyzx!sq!msb
From: msb@sq.UUCP
Newsgroups: comp.lang.c
Subject: Re: Printf format strings
Message-ID: <1987Apr6.173449.1341@sq.uucp>
Date: Mon, 6-Apr-87 17:34:49 EST
Article-I.D.: sq.1987Apr6.173449.1341
Posted: Mon Apr  6 17:34:49 1987
Date-Received: Mon, 6-Apr-87 23:49:52 EST
References: <782@kodak.UUCP>
Reply-To: msb@sq.UUCP (Mark Brader)
Organization: SoftQuad Inc., Toronto
Lines: 28
Keywords: printf, print formatting.
Checksum: 10141
Summary: ANSI draft unclear

> 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