RE: [pkcs11] CK_ULONG considered harmful?

[Chris Zimman <czimman@bloomberg.com>]

> These issues inevitably will come up in network protocols. It's quite a common issue.

I would say that most of the network protocols I've seen, in one way or another, specify sizes exactly. 

> The server (HSM) will know the exact definition of the CK_ULONG that the client uses. The client-side PKCS#11 library will pass this information to the server (due to the 1:1 
 > match of the library to the architecture that I described in the previous e-mail).

Whether it knows it or not, it can't deal with having it be a different size.  If I create an attribute that's a CK_ULONG, and happens to contain a value > 32 bits, I cannot ever read it back on something where a CK_ULONG is a 32 bit size.

> 1. The value in question actually fits the range of [0,2^32], i.e. 
> whether one always has (unsigned)x == (unsigned long long)x regardless of how much memory x takes. It's then just a matter of casting and using the right type internally. For > example, the system that does the processing on 32 bit system is expected to use the a 32 bit working value for efficiency/simplicity. 64 bit arithmetic will incur unnecessary
> overhead, compiler warnings, etc.

How do you fit a 64 bit value into a 32 bit type?
 
> 2. The value may exceed 2^32. Then the truncation is possible and this can be an error in some (rare) cases.

There's nothing to handle this condition right now -- again, because of ambiguously specified types.  In any event, this is not acceptable behavior from my perspective.

> One should try to avoid #2. There are two ways to do so: the standard can do its part and applications/implementation can help regardless of the recognition of this issue by 
> the standard.

"...should try to avoid..." -- yes, I agree -- the spec should not allow it.  Vendors should not be free to come up with whatever way they feel is best for dealing with this type of behavior.  Not if we're ever at all interested in interop anyhow.

> If these are enumerations, flags fields, the values should be constrained to the lower 32 bits by the standard (or the standard is broken on 32 bit systems).
>
> HANDLEs (as pointers) are not network-portable and must be re-mapped, so that seems fine. If implementation needs portability of things like CK_SLOT_ID, it should maintain 
> it under  the 2^32.
[--snip--]

Basically, in effect, you're suggesting making CK_ULONG into uint32_t 

> Other alternatives that don't work IMO:
> *) fix CK_ULONG at 32 or 64 bit. POSIX, STL, etc use size_t and the compatibility between CK_ULONG and size_t is then an issue pushed up to the caller.

FWIW, last time I checked, size_t and unsigned long aren't even guaranteed to be the same size.

--Chris