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

[bruce.labitt at autoliv.com]

gnhlug-discuss-bounces at mail.gnhlug.org wrote on 09/11/2009 11:06:32 AM:

> 
> 
> In just the few minutes I had to actually look at that pack2.c I found
> several scary sequences of code, so if you're staying your current 
course
> (instead of adopting some of the other recommendations offered here)
> you might want to keep on looking or else write your own from scratch.
> 
> For example, in unpack() (where f is a pointer-to-float) we see code
> like this:
> 
>         case 'f':
>             f = va_arg( ap, float * ); // WTF?
>             pf = unpacki32( buf );
>             buf += 4;
>             *f = unpack754_32( pf ); // Aaieeee!!
>             break;
> 
> ...and in main() we see him squirt some data into buf[] and then
> immediately overwrite part of it "for kicks":
> 
>     packetsize = pack(buf, "chhlsf", 'B', 0, 37, -5, s, -3490.6677);
>     packi16(buf+1, packetsize); // store packet size in packet for kicks
> 
> These aren't the droids you're looking for...
> 

Perhaps not.  beej's code is a bit unusual.  So is his book.  I would 
never dream of coding that way - I'm not very good at C, so I'd never even 
think to do such a thing.

Nonetheless, I solved my problem for the 2^53 issue.  That was a cast of a 
cast problem.  Operator error.  :P

I can now send chars, 16, 32, 64 bit ints, 32 bit floats, and 64 bit 
floats (aka double) 'portably' over the network.  (At least for a 64 bit 
OS).  Seriously, people, this wasn't THAT hard.  You just have to be 
persistent, or stubborn...  Why this stuff keeps on being reinvented is 
beyond me.  I've contacted the original author and asked if my code can be 
added to his example, so others won't go through this.

Carry on.  Back to your previously scheduled discussion...

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