Portability and alignment constraints

[Guy Harris]

> >Exchanging binary data has more than just alignment problems: aside
> >from integer endian-clashes, there are a multitude of floating point
> >formats.  Not even the number of bits per byte is fixed.  Portable
> >programs rely on some other method of exchanging data (RPC library,
> >ASCII interchange, etc.).
> 
> The portable method of writing binary data is to output a series of
> bytes, each containing 8 bits of data, LSB first.

This doesn't refer to a *particular* way of doing things; ASCII interchange
certainly outputs "a series of bytes, each containing 8 bits of data (although
one of them will always be zero)...".

If you are referring to, say, dumping a 32-bit quantity out by dumping it as 4
8-bit bytes, in a particular order, that is certainly *a* way, but equally
certainly not *the* way.  ASCII interchange is another; for that matter, the 4
bytes can be dumped in any one of several byte orders.

Also, byte order is the least of your problems with floating point.  You can
dump floating-point numbers in printable ASCII, or can convert them to some
"canonical" floating-point format and dump that in some standard byte order;
however, you have to choose the contents of the bytes in the series that you
dump - you can't just dump the bits (unless the "canonical" form happens to be
identical to the internal form on your particular machine).

> My point here is not that you are wrong, but that the problem is
> resolvable without vast trickery, and that there are some of us who are
> doing it.

I don't think Chris was saying it required "vast trickery" - I don't think
*anybody* would say it required "vast trickery", especially not for integral
data - just that it involved more than dumping out structures with some
standard alignment.