| Subject: | GSSAPI opaque types should be pointers to opaque structs, not void* |
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.
-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.