Change in K4 ticket cache format

[Alejandro R. Sedeno]

A little progress report and some questions.

I've put some thought into the big-endian system alignment records and
came up with some. I'd appreciate it if someone would look over them as
a sanity check. They're available at:

/afs/athena.mit.edu/user/a/s/asedeno/Public/krb4-big.txt

or 

http://web.mit.edu/asedeno/Public/krb4-big.txt

The quick summary is that there are four records, for the case of an
issue_date with 0-3 NULL bytes in it. I'm assuming the MSB will never
again be NULL. By the time this assumption becomes false, krb4 should be
long buried, and besides the field is too small to deal.

So my questions are:

Is there a recommended way for checking byte order? I can implement a
runtime check, but if there's a proper/preferred way to do it at compile
time I'd rather do it that way.

Should I care about catching the case in which there are three NULLs in
issue_date? This will only happen once every 6.37 months for a second,
and it seems like a waste to check for it. Even if I do catch it, other
32-bit issue_date libraries will choke on it since the service will come
out with an empty realm.

Should writing out the alignment record be run-time configurable, and
what should the default behavior be?

Any other input on this?

-Alejandro