Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!uxc!tank!eecae!shadooby!sharkey!bnlux0!drs
From: drs@bnlux0.bnl.gov (David R. Stampf)
Newsgroups: comp.sys.encore
Subject: Re: Compiler bug or insuficient language definition ?
Message-ID: <1172@bnlux0.bnl.gov>
Date: 2 Jun 89 00:47:49 GMT
References: <50537@tut.cis.ohio-state.edu>
Reply-To: drs@bnlux0.UUCP (David R. Stampf)
Organization: Brookhaven National Lab., Upton, N.Y.
Lines: 37

In article <50537@tut.cis.ohio-state.edu> george@cis.ohio-state.edu (Karl Kleinpaste) writes:
>on the Multimax.  The following piece of code
>
>main()
>{
>  float f = 4.0;
>
>  printf("float = %f\n", f);
>  printf("float = %x\n", f);
>}
>
>on a sun and a pyramid will print both the floating point value (4.0) and 
>then the raw hex value showing how the floating point number is stored.
>On the Multimax the second value is reported as 0.  Is this (a) a compiler
>bug (b) a fuzzy area in the definition of C (c) other ?
>
>Thanks,
>---George Jones

	On the multimax, the sizeof(double) is 8 bytes, sizeof(long) is 4 bytes
and I would venture a guess that the floating format has the words in opposite
order from sun/pyramid.  The printf converts f to a double, then pushes it on
the stack which looks like this.

			00000000	<- least sig. bits of 4.0
			04010000	<- or something like this for msb

	The %x (or %lx) picks off the top one and obediently prints 0.  If you
had written instead:

	printf("%lx %lx\n",f);

	you would see the correct format.  Had you said f = 2.0/3.0, you would
have seen something that looked better, but it would have been wrong, since you
would only see the lower bits.

	< dave