2010/1/3 Han Hartgers <[email protected]>:
> Dear Ludovic,
>
> Thanks for looking into this. It is good to know that this problems does not
> happen with the SVN version of  pcsc-lite.
>
> It would be interesting to know if SVN solves also the issues of the others
> on the ARM platform.
>
> Both the Sheeva (my problem and John Bougs) as the Kuro-box pro (debian
> error report) are based on a Marvell processor. Maybe there is something
> with that ARM version which is triggered by some kind variable casting....
> At the other hand the linux kernel and other software seems to get easily
> through the compiler. So the problem cannot be too big.
>
> Interesting that the "-fno-strict-aliasing" is not helping for the testpcsc
> application. It did make a difference for my application using the library.
>
> That the bytes are getting inverted can maybe mean that it has something to
> do with the sign of a two complement code. Are all "hcard" of the same
> unsigned int type?

SCARDHANDLE hCard with
typedef long SCARDHANDLE; /**< \p hCard returned by SCardConnect() */

int32_t hCard;

So one is a "long" and the other is a "int32_t". They are both signed integers.

> PS I hope that you do not mind that I put the list back on the cc.

No problem.

-- 
 Dr. Ludovic Rousseau

_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle

Reply via email to