[krbdev.mit.edu #4057] GSSAPI opaque types should be pointers to opaque structs, not void*

[Alexandra Ellwood via RT]

In other words:

-typedef void * gss_name_t;
+struct gss_name_struct;
+typedef struct gss_name_struct * gss_name_t;

-typedef void * gss_cred_id_t;
+struct gss_cred_id_struct;
+typedef struct gss_cred_id_struct * gss_cred_id_t;

-typedef void * gss_ctx_id_t;
+struct gss_ctx_id_struct;
+typedef struct gss_ctx_id_struct * gss_ctx_id_t;

The problem with using void* in a C API is that it prevents static type checking.  As a result 
it's far too easy for callers to accidentally pass random things into GSSAPI function that take 
these types without noticing.  Because the our implementation does pointer validation, these 
types of errors often turn into runtime errors such as memory leaks which go unnoticed for a 
long time.

For reference purposes, here are the specifications of the opaque types in RFC 2744:

3.5. Credentials

   A credential handle is a caller-opaque atomic datum that identifies a
   GSS-API credential data structure.  It is represented by the caller-
   opaque type gss_cred_id_t, which should be implemented as a pointer
   or arithmetic type.  If a pointer implementation is chosen, care must
   be taken to ensure that two gss_cred_id_t values may be compared with
   the == operator.
[...]
3.6. Contexts

   The gss_ctx_id_t data type contains a caller-opaque atomic value that
   identifies one end of a GSS-API security context.  It should be
   implemented as a pointer or arithmetic type.  If a pointer type is
   chosen, care should be taken to ensure that two gss_ctx_id_t values
   may be compared with the == operator.
[...]
3.10. Names
[...]
  The gss_name_t datatype should be implemented as a pointer type. To
   allow the compiler to aid the application programmer by performing
   type-checking, the use of (void *) is discouraged.  A pointer to an
   implementation-defined type is the preferred choice.