Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!microsoft!donc
From: donc@microsoft.UUCP (Don CORBITT)
Newsgroups: comp.lang.c
Subject: Re: fscanf bug in TC (BC) C++ 2.0
Message-ID: <72088@microsoft.UUCP>
Date: 29 Apr 91 22:37:30 GMT
References: <1991Apr14.215819.16486@allgfx.agi.oz> <1991Apr16.141117.5065@odin.diku.dk> <26502@hydra.gatech.EDU> <1991Apr18.021515.1481@athena.mit.edu> <41392@cup.portal.com>
Reply-To: donc@microsoft.UUCP (Don CORBITT)
Organization: Microsoft Corp., Redmond WA
Lines: 28

In article <41392@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes:
>< that the algorithm is imperfect: if the program isn't using
>< floating point, %e, %f, and %g can't be needed, but they might
>< not be needed if the program is using floating point, either.
>< However, "program uses floating point" is in principle computable
>< at compile time, while "%e, %f, or %g might get passed to printf"
>< isn't.)

[deleted text with justification for following code]

>We might see code like this:
>
>	long data;

	[...]

>	printf( "%f", data );
>Oops!  No floating point at compile time but needed at runtime.

This is incorrect, since printf() is varargs, a float value passed would
be expanded to double.  I would use a union here, if I wanted to do such
a thing.  Of course, someone will come up with such a program.  The fix
is simple, do some floating point math somewhere else in the program, 
even in a func that's never called.  

--
Don Corbitt
Microsoft Windows Development