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?


> Mapping the on-the-wire protocol can be tricky, but people do it every day.  You just need to ensure that you do the translation from the using system representation of ? ?
> CK_ULONG to an on-the-wire representation to a server representation.   And let's not even talk about how you deal with  pointers in a network encoding!
> I think that the network representation is out of the purview of this group mostly.

It's not really a problem of wire mapping etc at all -- explain to me how I'm going to get a value that's stored as 64 bit into a 32 bit client.  

> How about:
> 
> "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."
> This wouldn't be a change to the headers or anything else, just a description of the convention used for assigning values so that reasonable choices can be made to do network > protocol design (or even VM to VM type calls).

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.

--Chris


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