Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sdd.hp.com!spool.mu.edu!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: fscanf bug in TC (BC) C++ 2.0
Message-ID: <5310@goanna.cs.rmit.oz.au>
Date: 19 Apr 91 03:35:00 GMT
References: <1991Apr14.215819.16486@allgfx.agi.oz> <41392@cup.portal.com>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 27

In article <41392@cup.portal.com>, ts@cup.portal.com (Tim W Smith) writes:
> Suppose one of the types is single precision floating point.
> 	long data;
> 
> 	data = nextbyte() << 24;
> 	data |= nextbyte() << 16;
> 	data |= nextbyte() << 8;
> 	data |= nextbyte();

> 	printf( "%f", data );

> Oops!  No floating point at compile time but needed at runtime.
> ps: of course, I would never do this!

I'm so glad to hear that, as it doesn't do what you intended.
The %f format expects to find a DOUBLE value on the stack, which in TC
is 64 bits, but 'long' is only 32 bits.  [See the .signature.]  To make
this example work, it would need to be
	{ union {long L; float F;} pun;		/* we can't use a cast */
	  pun.L = data;				/* because we DON't want */
	  printf("%f", pun.F);			/* conversion */
	}
This, of course, "declares a floating-point variable", so the floating-
point routines should be linked in.
-- 
Bad things happen periodically, and they're going to happen to somebody.
Why not you?					-- John Allen Paulos.