Subject: the use of OM_uint32 in GSSAPI

From: Tom Yu <[email-masked]>
Date: Fri, 7 Nov 1997 20:58:01 -0500

This may have been discussed here before, but is there any good reason
to have explicitly sized types in GSSAPI?  In particular, the
definition of the API in terms of the type OM_uint32 seems somewhat
disturbing, since ANSI C, and probably some pre-ANSI C compilers as
well, guarantee that a long is at least 32 bits wide.

from draft-ietf-cat-gssv2-cbind-04:

   5.1.  Integer types

   GSSAPI uses the following integer data type:

        OM_uint32      32-bit unsigned integer

   /* ...deleted... */
               If the X/Open header file is not available on the platform,
   the GSSAPI implementation should use the smallest natural unsigned
   integer type that provides at least 32 bits of precision.

Does the qualifier "natural" indicate that a non-narrow type must be
used?  (nevermind that rfc1509 is even more vague) I don't have a copy
of the relevant X/Open spec, so I can't check.  If the type is
constrained to be non-narrow, then it becomes possible to use the
GSSAPI with non-ANSI compilers.  This may be important to some people;
I am not yet certain there are enough cases where this true to worry
about.

I see no good reason in the abstract not to use an unsigned long in
the place of OM_uint32, or even as an OM_uint32 by means of a typedef.
Practical considerations such as binary compatibility in the shared
library domain may be relevant, though.  Even these may be
surmountable by the shared library versioning systems available to
most platforms that implement shared libraries.

Even if it does become necessary to use the explicitly sized type
OM_uint32 in the GSSAPI, some additional clarification on whether or
not it may be a narrow type should be added to the draft, as the word
"natural" is vague.

---Tom