RPCSEC_GSS type names

[Wyllys Ingersoll]

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
and interoperability.  

>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.

-Wyllys

>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
>namespace).
>
>---Tom
>  
>