pkcs11 — archive

[Chris Zimman]

> 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.