From mboxrd@z Thu Jan  1 00:00:00 1970
Mime-Version: 1.0 (Apple Message framework v753)
In-Reply-To: <20071219203654.3714F1E8C1C@holo.morphisms.net>
References: <20071219203654.3714F1E8C1C@holo.morphisms.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <67C6BAFA-908C-4756-848F-4D65095913EB@mac.com>
Content-Transfer-Encoding: 7bit
From: dave.l@mac.com
Subject: Re: [9fans] fun and scary evil C code
Date: Thu, 20 Dec 2007 00:18:14 +0000
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Topicbox-Message-UUID: 1cd1219c-ead3-11e9-9d60-3106f5b1d025

> there, of course, we have a real compiler and don't have to
> write uvlong constants as floating point numbers
> (wow that seems fragile).

Scarily: they're not:
if you read on, that macro is for picking apart a double into bytes  
and vice-versa.
(i.e. it's insanity is internally consistent).
It's still ludicrous and fragile.

As far as I can see,
they're assuming that double is IEEE 754 and that you can
rip apart such a representation on an random-endian machine
and re-assemble it on an any other random-endian machine.

Does C99 or any other C mandate the actual memory layout
of floats and doubles or the exact conversion of constant  
representations?
I'm fairly sure they somehow mandate IEEE 754 properties,
but do they actually say that floats and doubles have to be stored  
exactly that way in 4 or 8 bytes?

Even if we assume sizeof(double) == 8,
what if my implementation is perverse and interleaves the exponent  
bits amongst the mantissa bits?
Where is this disallowed in the standard(s)?

DaveL