RPCSEC_GSS type names
wyllys.ingersoll at sun.com
Thu May 6 15:21:19 EDT 2004
Tom Yu wrote:
>This is the first of several messages regarding RPCSEC_GSS. This
>particular message concerns certain type names used in the API. I'm
>working on integrating the UMich RPCSEC_GSS implementation. Since an
>eventual goal is to have a public API, I'm attempting to put the
>header files in a state that makes them acceptable for installation.
>The gssrpc headers are not currently installed by "make install", as
>they contain questionable dependencies on autoconf-generated cpp
>macros and possible references to internal headers.
>Historical "free" implementations of RPC derive from several source
>code releases from Sun. The one in our source tree derives from
>rpcsrc-4.0, which is circa 1988. This code, as is typical of much
>code of the era, distinguishes poorly between implementation and
>interface, and also makes unportable assumptions about C types.
>A number of functions in the rpcsrc-4.0 API use the "u_long" (BSD
>alias for "unsigned long") type to represent certain 32-bit protocol
>quantities, such as program and procedure numbers. In our code, we
>have changed some of these to "rpc_u_int32" or something like that.
>It would be a good idea to use the C99 type "uint32_t" instead, where
>it is available. (POSIX has mandated uint32_t and related fixed-width
>integer types for some time.)
>Recent implementations of RPC in Solaris and NetBSD (among others) use
>specific types: rpcprog_t, rpcvers_t, etc., for protocol values.
>Unfortunately, these seem to have been introduced in tirpcsrc-2.8
>(a.k.a. tirpcsrc_99), which I seem to recall has some annoying
>conditions in its license that might make it problematic for us to
>distribute the code. I suspect that using simply using the type names
>in tirpcsrc-2.8 is safe, though.
I think this fear of the TI-RPC license is largely unfounded. I believe
it is a fairly open license (I havent read it in a while), the whole
purpose of releasing that code was to encourage other implementations
>I propose using uint32_t and int32_t for most of the places where
>rpc_u_int32 and rpc_int32 are currently used. I also propose using
>the rpcprog_t, rpcvers_t, rpcproc_t, rpcprot_t, rpcport_t, and
>rpc_inline_t types from tirpcsrc-2.8.
Sounds good to me.
>Also, I'm considering defining the BSD type aliases u_int, u_long,
>etc. in rpc/types.h on platforms which lack them, so that diffs
>against rpcsrc-4.0, etc. aren't quite as annoying to read. This does
>impinge upon the user namespace, but many OSes already define these
>aliases anyway (if not compiling with a standards-conforming
More information about the krbdev