On 7/29/2010 3:41 PM, Ludovic Rousseau wrote:
> 2010/7/29 Douglas E. Engert:
>> Today I sent a message to the Muscle list, that said:
>>
>>> The situation I was running into is with the ccid-1.3.13/src/commands.c
>>> The SecurePINVerify routine takes a TxBuffer described in PCSC part10
>>> secti
2010/7/29 Douglas E. Engert :
> Today I sent a message to the Muscle list, that said:
>
>> The situation I was running into is with the ccid-1.3.13/src/commands.c
>> The SecurePINVerify routine takes a TxBuffer described in PCSC part10 section
>> 2.5.2 PIN_VERIFY. Section 2.5.1 say the structures i
On 7/29/2010 1:40 PM, Ludovic Rousseau wrote:
> Does the compiler on Solaris also defines __BIG_ENDIAN__ where needed?
Almost, it will define _BIG_ENDIAN or _LITTLE_ENDIAN
The /usr/include/sys/isa.defs.h will use what the compiler sets for the
archetecure like "sparc" to set _BIG_ENDIAN
or _LIT
Today I sent a message to the Muscle list, that said:
> The situation I was running into is with the ccid-1.3.13/src/commands.c
> The SecurePINVerify routine takes a TxBuffer described in PCSC part10 section
> 2.5.2 PIN_VERIFY. Section 2.5.1 say the structures in section 2.5 will be:
> "Byte order
2010/7/27 Douglas E. Engert :
> On a Solaris 10 sparc machine, using pcsc and opensc both from
> svn, there appears to be a mismatch of handing the length
> field within the message for using a pin pad reader.
>
> pcscd trace shows:
>
> 0126 ../../src/src/ifdhandler.c:1307:IFDHControl() Control
On a Solaris 10 sparc machine, using pcsc and opensc both from
svn, there appears to be a mismatch of handing the length
field within the message for using a pin pad reader.
pcscd trace shows:
0126 ../../src/src/ifdhandler.c:1307:IFDHControl() ControlCode: 0x42330006,
usb:076b/3821:libusb:/d
