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? Greetings, Han PS I hope that you do not mind that I put the list back on the cc. On Sun, Jan 3, 2010 at 6:04 AM, Ludovic Rousseau <[email protected] > wrote: > I can't reproduce the problem using the SVN version. > I can reproduce the problem using version 1.5.5. But using > -fno-strict-aliasing does not solve the problem. > > What happens is strange. > > I instrumented the code (winscard_clnt.c line 2433) like this: > printf("%s:%d %lX %X\n", __FILE__, __LINE__, hCard, > scControlStructExtended->hCard); > scControlStructExtended->hCard = hCard; > printf("%s:%d %lX %X\n", __FILE__, __LINE__, hCard, > scControlStructExtended->hCard); > > I have the output: > winscard_clnt.c:2433 13469 0 > winscard_clnt.c:2435 13469 34690001 > > Note that 34690001h is 13469h but with the two 16bits words inverted. > I don't know what is causing that. > > Bye > > -- > Dr. Ludovic Rousseau >
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
