OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [pkcs11] CK_ULONG considered harmful?


On 05/20/13 02:46 PM, Chris Zimman wrote:
I think the right thing to do here is for me to withdraw this comment (unless someone comes up with an actual problem encountered).

I don't think withdrawing it is necessary -- it's just something that might be better left until 3.0.  Having non-exact specified types is bad, and it can lead to a wide variety of problematic situations.  The most simple example is where a token and interface disagree on the size of a CK_ULONG.  For example, a token that's internally 64 bit and can support 64 and 32 bit clients:  If the 64 bit client creates an object that contains an item with a 64 bit CK_ULONG value inside of it for whatever reason, there's no way for the 32 bit client to understand it since it may contain a value greater than 32 bits.  Both things have been operating legally.  Also, what is a 64 bit client supposed to do if it tries to submit a value to a 32 bit token in a CK_ULONG that exceeds 32 bits?  The token will have to reject it, but there aren't even error codes to handle all the cases.  Granted, most values fit into a 32 bit size, but that's more coincidence vs. good design.




I agree with this, and what Darren brought up earlier: in 3.0, let's
use explicit types from the get-go and save these heartaches later
on down the line.

Valerie
--
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
Solaris Cryptographic Technologies, Manager, Oracle Corporation
Now appearing in "9 to 5" the Musical! June 29-July 27, 2013
      West Valley Light Opera: http://www.wvlo.org/


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]