RE: [pkcs11] CK_ULONG considered harmful?

[Chris Zimman <czimman@bloomberg.com>]

> > That's just basically saying CK_ULONG == uint32_t.  Instead of trying to make kludges, let's just admit this was a mistake in the past and move on in the future.
> No, it's actually not.  What I'm saying is that we're preserving the bi-map between 64 and 32 bits, but that the OS can actually use whichever internal representation it wants for > efficiency.

That's not really the point here -- I don't care whether it's a uint32_t or a uint64_t, but it needs to be something consistent.  Just saying "it can be whatever, but in practice, it's limited to 32 bits" is just hiding the problem, not fixing it.  If it's a fixed size, you are still free to use whatever size you choose to contain it locally in your OS.  I can certainly use an uint64_t to hold a uint32_t if that for whatever reason makes more sense on my platform.

The issue in my mind also has nothing to do with compiler linkage, etc.  It has everything to do with allowing two or more things to determine arbitrarily what the maximum size of something can be and then expecting them to work together.  Since you've suggested:

> "Although the internal representation for a CK_ULONG may be 32 bits or longer, by convention, only the least significant 32 bits shall be used to represent PKCS11 data values 
> (with the one exception of the ~0UL value *sigh*).  This permits a loss-less conversion from a CK_ULONG 32 bit value to a CK_ULONG 64 bit value and vice versa."

...you can obviously see that there is an issue here as well.  What's the advantage of allowing a CK_ULONG to be > 32 bits if it can only hold 32 bits?
 Whether we change CK_ULONG to uint32_t or every time I access any value, I just (val & 0xFFFFFFFF), I end up with the same thing.  That being the case, anyone who wants can just update the definition to uint32_t and gain the same thing for free.

With things the way they currently are though, I can send an attribute value of 0x1234ABCD987654321 to your token and expect you to deal with it.  Your token may or may not be able to deal with it.  Then, someone else can come along on their 32 bit client, and try to retrieve that value, and not be able to deal with it.  Of course another alternative is to allow everyone to define their own CK_ULONG, so long as it's greater than 32 bits, but in that case, there's not a lot of point in worrying about inter op.

Again, I don't care about exactly what type anyone uses to hold it -- what I care about is that the size is a defined number of bits.  E.g.

/* an unsigned value, that will be >= N bits, but will hold at most N bits */
typedef [whatever type] CK_ULONG;

However, I'm still interested in understanding why if it's N bits, uintN_t is not the right value by default.  If a vendor wants to change it for whatever reason, that's upto them, but they then become responsible for making sure that CK_ULONG arguments are <= N bits in their code.
 
--Chris