[Haskell-cafe] Data.Binary and little endian encoding

[Tim Docker]

On a related matter, I am using Data.Binary to serialise data from
haskell
for use from other languages. The Data.Binary encoding of a Double is a
long
integer for the mantissa, and an int for the exponent.  This doesn't
work too well for interacting with other languages as I'd need to have
an arbitrary precision int type there to decode/encode. The CORBA CDR
standard encodes doubles in a big ended fashion like this (excuse my
possibly incorrect ascii art):


| byte | msb                   lsb |
|------+---------------------------|
|    0 | S   E6                 E0 |
|    1 | E10 E9 E8 E7 F3 F2 F1  F0 |
|    2 | F11                    F4 |
|    3 | F19                   F12 |
|    4 | F27                   F20 |
|    5 | F35                   F28 |
|    6 | F43                   F36 |
|    7 | F51                   F44 |

Up until now, my code is pure haskell.  Is it possible to get at the
internal bits of a Double/CDouble in ghc? Or Should I use the FFI and
write C to encode something like the above?

Tim

________________________________

From: haskell-cafe-bounces at haskell.org
[mailto:haskell-cafe-bounces at haskell.org] On Behalf Of David Leimbach
Sent: Friday, 15 May 2009 1:58 PM
To: Don Stewart
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] Data.Binary and little endian encoding




On Thu, May 14, 2009 at 8:54 PM, Don Stewart <dons at galois.com> wrote:


	> I'm speaking specifically of the encode/decode functions.  I
have no idea how
	> they're implemented.
	>
	> Are you saying that encode is doing something really simple
and the default
	> encodings for things just happen to be big endian?  If so,
then I understand
	> the pain.... but it still means I have to roll my own :-)  I
guess if one must
	> choose, big endian kind of makes sense, except that the whole
world is little
	> endian now, except for networks :-)  (No one *really* cares
about anything but
	> x86 anyway these days right?)
	
	
	Oh, 'encode' has type:
	
	   encode :: Binary a => a -> ByteString
	
	it just encodes with the default instances, which are all
network order:
	
	
http://en.wikipedia.org/wiki/Endianness#Endianness_in_networking
	


Yeah I understand that Big Endian == Network Byte Order... which would
be true, if I wasn't talking about Plan 9's 9P protocol which specifies
little endian bytes on the wire (as far as I can tell anyway from the
man page).

Dave
 

	
	-- Don