pkcs11 — archive

[Michael StJohns]

On 4/9/2013 6:06 PM, Tim Hudson wrote: It's all normative. Try doing anything meaningful in the way of interpretation without what you are suggesting is merely informative text. Umm.. let me try this a slightly different way. The header files - in a way nothing else is in this spec - are *really* normative in that they mostly just get compiled in. They - more than anything else are the ICD between the HSM and the client code. The field name- specifically the naming convention ulPasswordLength vs pulPasswordLength isn't going to be interpreted by the compiler. The text in the body of the document that describes the field as "length of password" vs "pointer to length of password" isn't going to be seen by the compilers, and a good compiler is going to flag the use of a long vs a pointer to an long during the compile. So given the choice between confusing humans - slightly - and putting out two different versions of the same structure in a header file and confusing the computers, I'd rather confuse the humans, especially since we can add comments to both the header file and the spec to describe what happened. Or again, we change the name of the structure, deprecate the current version in the header file, deprecate the mechanisms that use the current version, create new mechanisms that do exactly the same as the old mechanisms but with a CK_ULONG instead of CK_ULONG_PTR in the appropriate place. Mike