pkcs11 — archive

[Chris Zimman]

> 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. Is there an assumption here that the PKCS11 stack is always running on one platform? > 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). For example: You have a remote token, say a network HSM -- how is it supposed to deal with CK_ULONG if it gets values that a 64 bits in some cases and 32 bits in others? What does it do if a client that treats CK_ULONG as 32 bits requests an object (say a CKA_TOKEN object) that was created by something where CK_ULONG was 64 bit? Clearly it's not going to work, but the spec doesn't currently have a way to deal with this case. Also, what is a token that's 32 bit internally supposed to do with a value that's sent from a 64 bit CK_ULONG client? --Chris