Re: [pkcs11] CK_ULONG considered harmful?

[Andrey Jivsov <Andrey_Jivsov@symantec.com>]

On 05/20/2013 02:46 PM, Chris Zimman wrote:
> > I think the right thing to do here is for me to withdraw this comment (unless someone comes up with an actual problem encountered).
> I don't think withdrawing it is necessary -- it's just something that might be better left until 3.0.  Having non-exact specified types is bad, and it can lead to a wide variety of problematic situations.  The most simple example is where a token and interface disagree on the size of a CK_ULONG.  For example, a token that's internally 64 bit and can support 64 and 32 bit clients:  If the 64 bit client creates an object that contains an item with a 64 bit CK_ULONG value inside of it for whatever reason, there's no way for the 32 bit client to understand it since it may contain a value greater than 32 bits.  Both things have been operating legally.  Also, what is a 64 bit client supposed to do if it tries to submit a value to a 32 bit token in a CK_ULONG that exceeds 32 bits?  The token will have to reject it, but there aren't even error codes to handle all the cases.  Granted, most values fit into a 32 bit size, but that's more coincidence vs. good design.

Given similarity between size_t and CK_ULONG, would you say that size_t 
is not exactly specified? Pointers are other types with similar properties.

I think that it's debatable to say that an APi that uses size_t is not 
fully specified. size_t becomes a part of the Application Binary 
Interface (ABI). It's a flexible type if one considers different 
architectures, but that shouldn't cause problems.

Consider two examples, size_t is 32 or 64 bit on a respective platform. 
Given that there must be two binaries for the PKCS#11 library, each one 
of them is never confused what its view of size_t is. I am not aware of 
any platform that can bind a 32 bit binary with a 64 bit binary. Of 
course, we assume that the client must match the definition of the 
CK_ULONG, assisted by the compiler warnings or errors (that's a part of 
ABI). In many cases it's impossible to "bind" to an exported library 
function using the incorrectly defined type, i.e. an interface with the 
wrong definition of size_t (because of the platform-specific protection 
that makes cumulative size of parameters a part of the function 
signature -- as on Windows, for example).

Perhaps I missed something, in this case I would appreciate a more 
specific example that shows a problem.

Thank you