[882] 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_sky.c init_ctx.c pr_to_salt.c preauth.c princ_comp.c rd_req_dec.c recvauth.c send_tgs.c sendauth.c unparse.c
daemon@ATHENA.MIT.EDU (John Gilmore)
Thu Mar 2 00:46:40 1995
To: krbdev@MIT.EDU
In-Reply-To: Your message of "Wed, 01 Mar 1995 23:22:27 +0500."
<9503020422.AA17011@dcl.MIT.EDU>
Date: Wed, 01 Mar 1995 21:46:32 -0800
From: John Gilmore <gnu@cygnus.com>
> A few small changes for 16 vs 32 bit, pulling in winsock for network byte
> ordering and removed some unused local variables.
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).
I also noticed that the code is now casting the result of ntohX to
other types! This should never be done; you should know EXACTLY what
type you are running through ntohX and should never need to cast its
result.
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?
The BFD library has tiny macros and functions that automate this, if
you care.
John
