Packing/unpacking binary data in C - doubles, 64 bits

[bruce.labitt at autoliv.com]

Dana Nowell <DanaNowell at cornerstonesoftware.com> wrote on 09/10/2009 
05:06:24 PM:

> Bruce/Ben,
> I've some experience with binary oriented endian issues on about 15
> different platforms (Sun, SGI, Intel/AMD Windows PCs, Tandem/Compaq/HP
> NonStop 'mainframes', HP UX workstations, Linux, DEC Unix, and several
> flavors of Unix that probably do not still exist).  Basically INT signed
> or unsigned byte swaps (hton/ntoh for 32 bit and custom for 64 bit) have
> always worked as far back as I can remember (about 15 years).  Float and
> doubles are ALWAYS a pain as different, non endian related, format
> standards exist.
> 
> I assume since this is up for debate, that this is a homegrown protocol
> and there is no defined and documented 'network standard' format. The
> simplest and most obvious answer is pick one (which you seem to be
> trying to do).  Which one is a bit more complex as this long winded post
> will hopefully show.
> 

Thanks for your well thought out post.

I think my standard is simple.  Integers are converted to big-endian. 
Floats/doubles are converted to IEEE-754-2008 format and then converted to 
network format.  I'm not trying to make a career of this, just something 
that works well enough so I can get my job done.  A bonus is if it is a 
wee bit portable.  The development tools on PC's are way better than on 
the Cell.


<snip> 
> It appears you dislike suggestions of 'use ASCII' as they are space
> inefficient but yet you seem to want a 'standard'.  Well my experience
> tells me that the new 'standard' is ASCII/XML, the old 'standard' is
> something along the lines of IEEE 754 
<snip>

IEEE-754 is more than good enough.  I do find it hard to believe for 
engineering heavy work that the standard is ASCII...

> 
> Good luck.
> 
> 

I'll need it :)  Thanks!

Bruce


******************************
Neither the footer nor anything else in this E-mail is intended to or constitutes an <br>electronic signature and/or legally binding agreement in the absence of an <br>express statement or Autoliv policy and/or procedure to the contrary.<br>This E-mail and any attachments hereto are Autoliv property and may contain legally <br>privileged, confidential and/or proprietary information.<br>The recipient of this E-mail is prohibited from distributing, copying, forwarding or in any way <br>disseminating any material contained within this E-mail without prior written <br>permission from the author. If you receive this E-mail in error, please <br>immediately notify the author and delete this E-mail.  Autoliv disclaims all <br>responsibility and liability for the consequences of any person who fails to <br>abide by the terms herein. <br>
******************************