endian dilemma

[Kevin D. Clark]

"Jerry Feldman" <gaf at blu.org> writes:

> There is a 
> FIPS standard called asn.1

> So your encoding routine on the sending side would convert an integral (eg. 
> long) to a series of ascii characters

Well, if you're talking about using the most common ASN.1 encoding,
BER, then the encoded stuff isn't really ASCII -- it's binary.  ASN.1
and BER are also somewhat tedious and complex to work with (for
example, ASN.1 compilers can be a little bit unwieldy to work with).

But it's not impossible to work with ASN.1/BER...

> Sending binary data, even endian neutral, can be dangerous. For instance, 
> in C, the following structure indicates the problem.
> struct {
> 	char a;
> 	long b;
> };
> The size of the struct on a 32 bit CISC system might be 9 bytes, but on a 
> 32 bit RISC would be 8 bytes long, because field b must be aligned on a 32 
> bit boundary. On a 64 bit system (Alpha, PA RISC 2, Itanium), the structure 
> would be 16 byes long because of natural alignment. Additionally, 
> structures themselves might be aligned on special boundaries, which could 
> be 32, 64 or 128 bit aligned. So, the TLD stuff outlined above solves this, 
> but does add overhead. 

Sometimes, if the stars are in alignment (no pun intended!), you can
do things like:


struct Foo {
  uint32_t field1;
  uint64_t field2;
  uint32_t field3;
};

sprinkle some compiler #pragmas around this, as appropiate.  And then
you can be reasonably certain that the compiler did what you wanted if
you put <something like> this in your code:

assert(sizeof(struct Foo) == sizeof(Foo::field1) + sizeof(Foo::field2) + sizeof(Foo::field3));

Of course, the day that this assert() call throws an exception is the
day that you're in for some work.  But at least it won't die
silently...

Regards,

--kevin
-- 
Kevin D. Clark / Cetacean Networks / Portsmouth, N.H. (USA)
cetaceannetworks.com!kclark (GnuPG ID: B280F24E)
alumni.unh.edu!kdc