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

[Kevin D. Clark]

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?

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.

>   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.

IIRC, I haven't worked with a machine that didn't use a two's
compliment as its internal representation for integers in over two
decades, so I really am not enthusiastic about investigating this
particular problem.

Yeah, yeah, somebody might be tempted at this point to chirp up with a
statement like "but I used to use the lovely Frobozz 9000 machine
(which used one's-compliment) back in the 80's to perform ray-tracing
and accounting functions!!!", to which I will pre-emptively respond
"Yawn.".

>   What about floating point?

ASN.1 and BER/PER encoding...

Regards,

--kevin
-- 
GnuPG ID: B280F24E                God, I loved that Pontiac.
alumni.unh.edu!kdc                -- Tom Waits
http://kdc-blog.blogspot.com/