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

From: [email-masked]
Date: Wed, 4 Feb 1998 10:17:37 -0500

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

I didn't want to use "unsigned long" since there's no guarantee
that that's the smallest suitable integer type.  On a 64-bit machine,
it's perfectly possible that "unsigned int" will be 32 bits wide and
"unsigned long" will be 64.  The phrase is supposed to direct
the implementation towards choosing "unsigned int" on such a platform.

The reason for wanting to restrict this is an aid towards using the
C GSSAPI as an ABI, callable from other languages.  Different C
implementations on a single platform may choose different mappings
for the standard types (it may even be that our hypothetical 64-bit
platform provides compiler switches that make unsigned long be either
32 or 64 bits), and to get some measure of binary compatibility, I
wanted to try to be as explicit as possible about the size of types
(particularly types that appear inside structures).  It's certainly
not a complete solution to this problem - witness the discussion in
the ABI appendix about memory models, which is the pointer analog of
this issue - but I think it's a useful restriction.

Hence the term "natural" was supposed to imply "natural for the
underlying hardware" - e.g. on a machine with a byte-width of 9 bits,
a 36-bit integer type should probably be used, regardless of whether
a C implementation chooses to call that type an int or a long.

John

Tom Yu <[email-masked]> on 02/02/98 07:55:35 PM

 To:      [email-masked]                                    
                                                              
 cc:      (bcc: John Wray/Iris)                               

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

>   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