pkcs11 — archive

[Doron Cohen]

+1 …. to correct the header per Tim’s proposal below. The use of CK_ULONG_PTR in is clearly a typo and, I can attest that we already ship implementations where we treat it as a CK_ULONG instead of CK_ULONG_PTR regardless of the typo. While I understand the issue is backwards compatibility, and that other implementations follow the C header as is , I would also claim that in reality implementers have already made choices and there is significant inconsistency in the market which causes interoperability issues regardless. So, since we are here with the goal of updating the spec , my preference is that we SHOULD make it right and consistent with the wording (and rest of the spec) in 2.40 . Doron On 10/04/2013 7:36 AM, Michael StJohns wrote: I'd leave it as is. It's consistent in the text and in the header files. If it needs to be changed, then the proper way is to define a new structure and mechanism and leave this one intact. And I'm going to have to disagree here - in that the text itself does not support the typographical error in the structure definition. It states: ulPasswordLen length in bytes of the password information All the other references to CK_ULONG_PTR have a clear description along these lines: pulOutputLen pointer to the length in bytes that the output to be created shall have, has to hold the desired length as input and will receive the calculated length as output That the prose did not state " pointer to " means that it is not documented as being a pointer reference. And yes I do realise that there are other references to pointer types which don't start with pointer in their description (and they should) but there are only three CK_ULONG_PTR references in mechanism parameters - and the other two explicitly state "pointer to". Those descriptions that don't state pointer to that are actually pointers should be updated IMHO - the vast majority of items in the specification explicitly state pointer to - but there are some exceptions. It's unfortunate that no one has raised this before as clearly vendors have noticed it and made a choice (one way or the other). Leaving this little mess alone and not fixing it wouldn't be my preference - this like this which are clearly being interpreted differently by vendors should be fixed and now is the right time to fix it before we cement this in an OASIS specification. Tim. The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.