[1503] in Kerberos_V5_Development
Re: lib/rpc -> lib/gssrpc
daemon@ATHENA.MIT.EDU (Tom Yu)
Tue Aug 6 11:21:07 1996
Date: Tue, 6 Aug 1996 11:20:56 -0400
To: Marc Horowitz <marc@MIT.EDU>
Cc: Tom Yu <tlyu@MIT.EDU>, krbcore@MIT.EDU
From: Tom Yu <tlyu@MIT.EDU>
In-Reply-To: <9608060729.AA17135@portnoy.MIT.EDU>
>>>>> "Marc" == Marc Horowitz <marc@MIT.EDU> writes:
Marc> Well, I'm not sure how renaming stuff in the distribution
Marc> changes anything. If you mean that you want to install the
Marc> rpc headers as gssrpc/*.h, then you should be careful to
Marc> document that using gssrpc headers and the vendor's rpc
Marc> headers in the same program is unlikely to work. gssrpc
Marc> should be compatible with the vendor rpc, though.
We already have problems with namespace collisions, e.g. rpc/netdb.h
and rpc/types.h, where header files in our build tree shadow the
system header files. This is not a good thing. For example, look at
the recent changes I have had to make to the lib/rpc directory in
order to get it to even compile on some platforms; they are rather
ugly, and we really should find and eliminate the underlying problem,
which is header name collisions.
* netdb.h (and other system headers) are not always protected
against multiple inclusion. This is an unfortunate fact of
life. This is mostly fixed by having our rpc/types.h not
include netdb.h, and only including our rpc/netdb.h.
* netdb.h on some platforms includes rpc/netdb.h in order to
get struct rpcent. This file gets shadowed by our own
rpc/netdb.h, which also tries to declare struct rpcent. This
causes a number of problems.
* We have our own rpc/types.h. This may cause other problems
later down the line.
Several possible solutions come to mind.
* Remove our own rpc/netdb.h and put the declarations in our
rpc/types.h.
* Rename $(BUILDTOP)/include/rpc to
$(BUILDTOP)/include/gssrpc; this defeats the purpose of being
a drop-in replacement for the vendor rpc support, as marc
points out.
* 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. A quick scan through the source tree reveals
that not too many things outside of lib/rpc include rpc/*.h, but it
would also be a minor pain to go through all the lib/rpc sources and
rename stuff.
---Tom
