CK_ULONG considered harmful?

[Michael StJohns <msj@nthpermutation.com>]

In the current version of the spec, the definition for CK_ULONG and 
CK_LONG are "integers at least 32 bits wide".

Given this spec is at least in part an interface spec, there can be an 
issue where the client uses a CK_ULONG of 32 bits and the driver uses a 
CK_ULONG of 64 bits (for example) or vice versa.  The text in the 
section says:

> It follows that many of the data and pointer types will vary somewhat 
> from one
> environment to another (e.g., a CK_ULONG will sometimes be 32 bits, 
> and sometimes
> perhaps 64 bits). However, these details should not affect an 
> application, assuming it is
> compiled with Cryptoki header files consistent with the Cryptoki 
> library to which the
> application is linked.

But that means that it is difficult to build client code built for 
adaptation (e.g. something like java bridge to JCE and NSS for Mozilla) 
that is library agnostic.


Proposal:

1) Option 1 - Leave it as it is

2) "Clarify" the language and force things to 32 bits.
Change the base definitions  (page 11, section 2 of the 2.40 draft) to:

typedef  uint32_t CK_ULONG;
typedef int_32_t CK_LONG;
typedef uint8_t CK_BYTE;

and update the text accordingly.

3) Fix things for new items:

Add the following definitions:

typedef uint32_t CK_ULONG32;
typedef int32_t CK_LONG32;
typedef uint8_t CK_BYTE8;

And use these values for all future definitions and mechanisms.  (I 
mostly don't like this idea because of having CK_ULONG32 and CK_ULONG, 
provided for completeness).

4) Option 2 or 3 above, but we provide a migration path:

Add a C_GetAlternateFunctionList:

CK_DEFINE_FUNCTION (CK_RV, C_GetAlternateFunctionList) (
   CK_FUNCTION_LIST_PTR_PTR ppFunctionList,
   CK_UTF8CHAR_PTR pListName
 );

Some drivers already do something like this to let you get the FIPs vs 
the non-FIPS version of the routines.

If you did C_GetAlternateFunctionList (&pk, "ULONG32"), you'd get a set 
of routines where the internals for CK_ULONG were all guaranteed to use 
32 bits, similarly for "ULONG64".

There would be some additional #ifdefs in the header file so that the 
user could do the right thing.

Mike