Xref: utzoo unix-pc.general:7059 comp.sys.att:11364
Path: utzoo!utgpu!watserv1!watmath!uunet!fernwood!portal!cup.portal.com!thad
From: thad@cup.portal.com (Thad P Floryan)
Newsgroups: unix-pc.general,comp.sys.att
Subject: 3B1 C runtime library bug; do you have it too?
Message-ID: <37567@cup.portal.com>
Date: 4 Jan 91 11:56:47 GMT
Organization: The Portal System (TM)
Lines: 39

Incredible as it may seem, I believe I've actually found a bug in the 3B1's
C library.  Discovered this while porting something really neat to the 3B1,
so I checked it out on 4 other systems (Amiga w/Manx C and w/Lattice/SAS C,
VAX/VMS C 3.1, and HP-UX V7's C) which all produce the correct:

		01.230
		 1.230

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

On the off-chance I may have somehow screwed (or not updated (how?)) my C
runtime libraries or they got clobbered by some "random" install script for
some other package(s), would you please try this program on your system and
see if you get the correct results?

What the two "*" mean (in C) is that the precision and scaling values will be
supplied by the (correctly positioned) "int" arguments listed just prior to
the floating point value to be displayed in the printf().

Of course I can "work around" this, but I'd like to know if it's necessary to
do so (i.e. are only my libraries screwed or are everyone's screwed).

Here's the test program.  The problem occurs (on my systems) either with or
without the shared libs and with or without optimization and with cc or gcc.

main()
{
	int p = 3;
	double frac = 1.23;

	printf ("%0*.*f\n", p+3, p, frac);
	printf ("%*.*f\n",  p+3, p, frac);
}

Thad Floryan  [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]