[884] in Kerberos_V5_Development
Re: CVS report: src/lib/krb5/krb ChangeLog compat_recv.c copy_princ.c get_fcreds.c get_in_tkt.c in_tkt_pwd.c in_tkt_sk
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu Mar 2 21:28:28 1995
Date: Thu, 2 Mar 1995 21:28:23 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: John Gilmore <gnu@cygnus.com>
Cc: krbdev@MIT.EDU
In-Reply-To: John Gilmore's message of Wed, 01 Mar 1995 21:46:32 -0800,
<199503020546.VAA28900@cygnus.com>
Date: Wed, 01 Mar 1995 21:46:32 -0800
From: John Gilmore <gnu@cygnus.com>
The whole "ntohX" paradigm is wrong for what Kerberos is doing. It
assumes that you know the size of the thing you are "ntoh-ing", have
picked it up as an integer value, and want to swap it around. The
idea that you can just pick up a collection of bytes out of a packet
as an integer completely ignores alignment issues (both C-compiler
struct-alignment and machine word-alignment).
Yes, absolutely. ntohX() is the wrong thing.
You shouldn't need any include files to input a value in network byte
order as a particular number of bytes. Network byte order is
well-defined as big-endian. You input e.g. a 16-bit big endian value
by doing:
unsigned char *ptr;
anytype value;
value = (ptr[0] << 8) + ptr[1];
You output it with:
ptr[0] = (value >> 8) & 0xFF;
ptr[1] = value & 0xFF;
This doesn't depend on the byte order of the host, the size or type of
`value', the local machine's alignment of words or ints, the packet
layout's alignment of ints, etc, etc. It works on every kind of
machine. It doesn't require compile-time configuration. It's fast.
Krbdev, how do you feel about making the sources do this in preference
to what it does now?
Yes, we should do this. There are a few places where we've made this
transition already. I've generally been making the change when I'm
mucking around with a particular section of code and I stumble across a
ntohX() or htonX().
- Ted
