Subject: clarification on OM_uint32 in gssv2-cbind-05? (sized types == evil)

From: Tom Yu <[email-masked]>
Date: Mon, 2 Feb 1998 19:55:35 -0500

>   5.1.  Integer types
>
>   GSSAPI uses the following integer data type:
>
>        OM_uint32      32-bit unsigned integer
>[...]
>               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.

So... while personally I would prefer that no explicitly sized types
were to be used in the GSSAPI C bindings, given that ANSI C gives a
perfectly serviceable unsigned integer type guaranteed to be at least
32 bits wide, namely, "unsigned long", I would still like to request
clarification on the intent of the wording "smallest natural unsigned
integer type".

Does "natural" in that passage indicate "non-narrow"?  If so, that
should be made explicit.  I would also like to point out that using a
non-narrow type would also make the GSSAPI C bindings accessible to
programmers who are stuck using non-ANSI C compilers, whereas using a
narrow type would prevent this from happening.  If this is not the
case, then is the word "natural" actually redundant?  Any integer
types that are "unnatural" by other definitions, such as "long long",
etc., are not likely to include the shortest type that is at least 32
bits wide, given ANSI C's guarantee about the width of a "long".

Also, why can't we just throw the whole mess out the window and just
say "unsigned long" when we mean "unsigned integer type that privides
at least 32 bits of precision"?  I know that there are probably some
source code and binary compatibility issues at stake here, but I
certainly haven't heard terribly much about them, and am curious to
hear arguments in either direction.

---Tom

---

From: Mike Eisler <[email-masked]>
Date: Mon, 2 Feb 1998 18:14:58 -0800 (PST)

> Date: Mon, 2 Feb 1998 19:55:35 -0500
> From: "Tom Yu" <[email-masked]>
> Subject: clarification on OM_uint32 in gssv2-cbind-05? (sized types == evil)
> To: [email-masked]

[...]
> hear arguments in either direction.

Please leave OM_uint32 alone. I found it to be a good thing because it made the
port of GSS-API from ILP32 to the LP64 model much easier. 

(It would have been a non-port if the size_t data type hadn't appeared in
specification ... my application protocols were specified with 32 bit length's
in gss_buffer_desc_struct, and adding mapping code for the LP64 model was
annoying).

Sized types are good ... when the data model changes, one can preserve both
binary and source compatbility. They also simplify the encoding and decoding
of quantities on the wire.

	-mre

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 02 Feb 1998 23:57:50 -0500

>of quantities on the wire.

But they make porting to machines who don't support those particular
type sizes hell (try porting Kerberos to a Cray; you'll see what I mean).

--Ken