Re: [pkcs11] CK_ULONG considered harmful?

[Michael StJohns <msj@nthpermutation.com>]

On 5/17/2013 2:40 PM, Robert Relyea wrote:
> On 05/16/2013 10:07 AM, Michael StJohns wrote:
> > 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:
>
> So in practice this has meant that CK_ULONG is the length of the 
> unsigned long on the native platform, but needs to be at least 32 bits 
> wide (That is some theoretical 16 bit platform needs to have CK_ULONG 
> be able to hold a 32 bit value).  Since the client and the driver are 
> on the same platform (PKCS #11 is a linking, not wire protocol), they 
> should always agree on the actual length.

This is where I think there's a problem.

The header files define this as

typedef unsigned long int CK_ULONG;

But as someone else noted a while back, the header file used by the 
client may not actually be the header file used by the pkcs11 driver 
implementation.

Let's say that the client used:

typedef uint32_t CK_ULONG;

and the driver used

typedef uint64_t CK_ULONG;

Both would be in compliance with the PKCS11 spec (int at least 32 bits 
long), but there might be issues.

Another possibility is the driver uses  "typedef uint32_t CK_ULONG" and 
the client uses "typedef unsigned long int CK_ULONG" - what happens on 
the 64 bit OS?

I don't know what the current implementations do - part of the reason 
why I asked the question.

Mike