On 4/9/2013 5:48 PM, Tim Hudson wrote:
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
I'd claim that the CK_ULONG_PTR declaration is normative, while the
ulPasswordLen component name and descriptive text are informative.
If you want to fix the informative text, I'm OK with that. I'd
probably annotate this change as a footnote. I wouldn't change the
structure definition in either the text or the header. I probably
wouldn't change the name of the structure component either.
Mike
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.
|