Xref: utzoo unix-pc.general:7084 comp.sys.att:11381
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!rpi!uupsi!vmp!sonyd1.Broadcast.Sony.COM!blilly.UUCP!balilly.UUCP!bruce
From: bruce@balilly.UUCP (Bruce Lilly)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: 3B1 C runtime library bug; do you have it too?
Message-ID: <1991Jan5.174829.18682@blilly.UUCP>
Date: 5 Jan 91 17:48:29 GMT
References: <37567@cup.portal.com>
Sender: news@blilly.UUCP (News Administrator)
Organization: Bruce Lilly, Flushing, NY
Lines: 36

In article <37567@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes:
>
>All 3B1 systems I have here (with 3.5 & 3.5 dev. set and 3.51m w/3.51 dev set)
>produce the (incorrect) results:
>
>		*.*f
>		 1.230
>	printf ("%0*.*f\n", p+3, p, frac);
>	printf ("%*.*f\n",  p+3, p, frac);


It's not clear that this is, in fact, ``incorrect.''  From the printf(3S)
man page:

``A field width or precision or both may be indicated by an asterisk (*)
instead of a digit string.''
^^^^^^^^^^  N.B. it doesn't say ``in addition to.''

If you really need the '0' (to pad on the left with zeros), I suggest
generating a format string using sprintf, e.g.

char	fmt[30]; /* set size to taste */

...

sprintf(fmt, "%%0%d.%df\n", p+3, p)
printf(fmt, frac);

...

If the "%0*.*f" happens to do want you want on other systems, that doesn't
mean that that (unspecified) behaviour is ``standard.''

Good luck with your project.
--
	Bruce Lilly		blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM