[1510] in Kerberos_V5_Development
Re: lib/rpc -> lib/gssrpc
daemon@ATHENA.MIT.EDU (Sam Hartman)
Wed Aug 7 03:15:52 1996
To: Marc Horowitz <marc@MIT.EDU>
Cc: Tom Yu <tlyu@MIT.EDU>, krbcore@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 07 Aug 1996 03:15:40 -0400
In-Reply-To: Marc Horowitz's message of Tue, 06 Aug 1996 13:26:34 EDT
>>>>> "Marc" == Marc Horowitz <marc@MIT.EDU> writes:
Marc> In message <199608061520.LAA19234@dragons-lair.MIT.EDU>, Tom
Marc> Yu <tlyu@MIT.EDU> writes:
>>> * Leave things mostly as they are; let our rpc/netdb.h shadow
>>> the system one, and when the /usr/include/netdb.h includes
>>> rpc/netdb.h, it ends up with ours. Maybe the cpp symbol
>>> STRUCT_RPCENT_ALREADY_PROVIDED should be
>>> STRUCT_RPCENT_IN_RPC_NETDB_H (or something similar) to make it
>>> more clear what it really means, and also clearly comment the
>>> part of the configure.in that is relevant. The problem here
>>> is that it may mislead programmers into thinking that our
>>> gssprc and the vendor rpc headers are interchangeable, which
>>> they are not.
>>>
>>> I am beginning to think that the last option is likely to be
>>> the best one for our purposes.
Marc> I agree. I have made such changes to the cygnus tree, and
Marc> if I don't migrate them to MIT before I leave, someone else
Marc> here will.
I agree with clarifying the documentation but disagree with
Tom's wording because it is divergent from what happens. If the
system netdb.h includes rpc/netdb.h, we will shadow the system
rpc/netdb.h, and our multiple inclusion protection will not allow the
structure to be defined.
The problem is when the system netdb.h inlines struct rpcent.
We probably want to use STRUCT_RPCENT_IN_SYSTEM_INCLUDES or some
symbol name like that.
One potential problem we may need to consider is what happens
if one of our old rpc/netdb.h files (from a previous build/install
cycle) manages to make its way into the include path of a new build.
I can't see a likely way for this to happen, but if anyone else can,
we may have a problem.
--Sam
