[2691] in Kerberos_V5_Development
Re: More Unicos porting hell (struct inaddr)
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Fri Oct 31 17:04:47 1997
Date: Fri, 31 Oct 1997 17:04:02 -0500
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, Assar Westerlund
<assar@sics.se>,
krbdev@MIT.EDU
In-Reply-To: Ken Hornstein's message of Fri, 31 Oct 1997 13:56:19 -0500,
<199710311856.NAA03926@ginger.cmf.nrl.navy.mil>
Date: Fri, 31 Oct 1997 13:56:19 -0500
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
But, my changes still cause a memcpy() to be used. The question _I_
have is the use of the s_addr element of struct in_addr.
There is actually some code in Kerberos that just copies the address using
a pointer to struct in_addr. There is also some code that uses
in_addr.s_addr. Obviously, the former code has worked for a long time
on a bunch of systems.
I guess the question I have is what do people think about just using
a pointer to struct in_addr instead of a pointer to in_addr.s_addr.
That would be half of the work that needs to be done.
I just got some assurances from a colleague at work who serves as the
Athena release engineer and who is also a NetBSD kernel developer, and
he claims that we'd be safe using the address of the struct in_addr, as
opposed to inaddr.s_addr. A lot of code would break if that part of the
API ever changed.
(Part of the problem here is that the BSD Networking API isn't formally
specified *anywhere*, so what BSD and what other OS vendors might decide
to change is never really completely clear, sigh.)
The _other_ half is to do something like:
#ifndef SIZEOF_in_addr
#define SIZEOF_in_addr sizeof(struct in_addr)
#endif
and use SIZEOF_in_addr everywhere you needed the size of struct in_addr.
Can you explain to me again why you need the above?
- Ted
