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

Jerry Feldman gaf at blu.org
Thu Sep 10 12:29:04 EDT 2009


On 09/10/2009 10:12 AM, Kevin D. Clark wrote:
> Bruce Labitt writes:
>
>   
>> Kevin D. Clark wrote:
>>     
>>> 2:  Typically, binary stuff is sent over the network in "network byte
>>> order" and network byte order is big-endian.  This statement is not
>>> universally agreed to -- in fact I used to work at a shop where they'd
>>> never even considered this problem and it turned out that they were
>>> sending (most) stuff over the wire in little-endian format.
>>>
>>>   
>>>       
>> That only works if both ends are the same - definitely not portable.  In 
>> my case, the client is little-endian and the server is big-endian.
>>     
> No, that always works and it is definitely portable.  Read what I said
> again: when you transmit binary integers onto the wire, make sure they
> exist in network-byte-order.
>
> May I politely suggest that you consult a decent computer networking
> book?  Please take a look at the functions htonl() and ntohl().
>
>
>
> Question: from your various postings on this list, I gather that you
> are using MPI.  If this is true, why aren't you just using things like
> MPI_INT, MPI_DOUBLE, and possibly MPI_LONG_LONG?  Why not let your MPI
> library take care of details like this for you?  I guarantee you that
> any decent MPI implementation is going to be well-debugged and
> efficient.  It should also take care of any endian issues that you
> might encounter.
>
>   
Since this is my field of expertise I might as well comment. First, the
htonl(3) and ntohl(3) functions are designed for 32-bit integers only.
They will not work for 64-bit longs. (or long-longs). I suggest you use
the bswap_64 or bswap_32 macros. For data communication I strongly
recommend not sending binary integral or floating point data. Floating
point is also problematical. A C double (IEEE) is 1 sign bit, 11
exponent bits, and 52 mantissa bits. Certainly if you are using MPI,
then the MPI provided functions are useful.  Also,, I believe the bswap
macros are defined in the latest C standard, not the 1989.  Also, most
little endian systems (x86, Digital Alpha, IA64) implement these macros
to perform the proper byte swap into net byte order, and big endian
systems (such as Sun SPARC, HP PARISC and IA64 (HP-UX)) set the macros
as no-ops.  Many systems use a TLD (Type, Length, Data) notation to send
data. This way all data transmitted is in an ASCII (or EBCDIC) external
encoding so the reciving and sending systems can be of different
endians, or even have different integer sizes, such as 36-bits. remember
that the C language does not specify an integer size, just a range.
Today most 64-bit Unix/Linux systems use the LP64 notation, but windows
uses (I think but may be wrong ILP64). HP and IBM have some very good
online white papers and porting guides dealing not only with endians,
but also with 32-bit to 64-bit issues. I wrote some of the HP stuff and
most of it is still the text I wrote.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20090910/1c7d7c1d/attachment.bin 


More information about the gnhlug-discuss mailing list