Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!agate!pasteur!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Circumspect programming (was: Evaluation of if's)
Message-ID: <14678@dog.ee.lbl.gov>
Date: 25 Jun 91 21:35:59 GMT
References: <1991Jun20.012131.26756@athena.mit.edu> <1991Jun24.202840.26091@arcturus.uucp>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 26
X-Local-Date: Tue, 25 Jun 91 14:35:59 PDT

In article <1991Jun24.202840.26091@arcturus.uucp> berry@arcturus.uucp
(Berry;Craig D.) writes:
>... I recall reading an article somewhere ... on the semantics of C
>under ANSI standard floating point operations.

ANSI C says little about floating point operations (it leaves a lot of
details up to the implementor, and no doubt leaves others undefined; it
*does* constrain implementors to use binary representations).

>One point raised was that ANSI C specifically removes the requirement
>for "knothole" casts to floats; e.g., if you have an 80-bit value in a
>floating point register, and you cast it to double ... the extra 16
>bits (assuming 64-bit doubles) are *not necessarily* scraped off by
>the cast.  This could [a]ffect the value of something like
>a * (double) (b + c).

This is correct (except that `specifically removes' is overstating the
case).

>Now, assignment to a double *does* scrape off the excess bits, by definition.

This is not correct.  The C standard does not say if or when `extra'
precision vanishes.  This is sometimes problematical.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov