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

[bruce.labitt at autoliv.com]

gnhlug-discuss-bounces at mail.gnhlug.org wrote on 09/10/2009 04:33:10 PM:

> 
> Ben Scott writes:
> 
> >   We keep seeing the recommendation to use highly-portable encodings
> > when possible, e.g., ASCII, or some kind of self-descriptive encoding.
> >  Which I fully agree is a very good idea.
> > 
> >   But assume for the sake of discussion we want to keep overhead as
> > low as possible for performance reasons, and "wait until computers get
> > faster" isn't a practical solution.  What techniques, best practices,
> > de facto standards, popular libraries, etc., exist for this sort of
> > thing?
> 


FWIW, I have something working for doubles now.  And 64 bit integers up to 
2^53.  That sounds curiously like a floating point problem.  Packs and 
unpacks chars, 16 bit ints, 32 bit ints, 64 bit ints (with the limit 
noted) SP floats and DP floats. 

Any suggestions to look for a 2^53 type problem?

If I was any good at C, this would be A LOT EASIER... :P


> If somebody were to disallow me from suggesting a solution to this
> problem which relied upon ASCII text, then my next proposed solution
> would be to use ASN.1 with either a DER or PER encoding.
> 
> If you think that this is a better solution, then more power to you.
> 

I can't imagine ever using that.  I spent 3 minutes drilling down on their 
site.  From what I could glean, the ASN.1 standard effectively knows 
nothing about double or quad precision numbers, although it knows about 
arbitrary length integers.


> >   Obviously, putting unsigned integers into "network byte order" for
> > transmission is one such best practice.
> > 
> >   What about signed integers?  Can one expect hton*() and ntoh*() to
> > work for signed integers as well?  IIRC, most machines store signed
> > ints in two's-complement format, which I think would survive and work
> > properly if swapped to compensate for an endianess change, but I'm not
> > sure.
> 
> Yes, htonl() et al. work just fine with two's compliment machines.

The code snippet with all the uint64_t's ( htonll() ) dies for N>2^53.  So 
it is not so straight forward...

> 
> 
> >   What about floating point?
> 
> ASN.1 and BER/PER encoding...

Where is there a reference to sending DPFP in ASN.1 or BER/PER encoding, 
maybe I missed it?



Regards,
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>
******************************