Re: [pkcs11] CK_ULONG considered harmful?

[Andrey Jivsov <Andrey_Jivsov@symantec.com>]

On 05/16/2013 10:07 AM, Michael StJohns wrote:
> 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;

I always thought about CK_ULONG as an attempt to define a type like size_t.

I will assume that you are familiar with this dynamic type, which is 
essential for POSIX APIs and STL of C++ APIs.

Assuming there there is some intended relationship between to size_t and 
CK_ULONG, the bug in the CK_ULONG definition as

   typedef unsigned long int CK_ULONG;

is that the long is 32 bit on Windows 64 bit.


One downside that I see with defining CK_ULONG as a 32 bit type is that 
this will generate warnings and in many cases errors in a correct 
application code.

The problem is that uint32_t is incompatible with size_t. Assigning wide 
type to narrower is often an error (typically in C++ code). For example, 
if I am to use

   vector<uint8_t> buffer;

then its size, buffer.size(), is size_t.

This reality commonly dictates that the types that are used for size 
parameters in the APIs are size_t (or able to accommodate one, such as 
explicit uint64_t, but this is often wasteful in register allocation, etc).

Given all this, the reduction of CK_ULONG to 32 bit type will probably 
hurt more than help.