On Wed, 2010-09-15 at 11:43 -0500, Douglas E. Engert wrote: > > On 9/15/2010 6:30 AM, Martin Paljak wrote: > > Hello, > > On Sep 15, 2010, at 12:12 PM, Viktor TARASOV wrote: > >>> Not yet! I had to replace line 122 of iso7816.c > >>>> assert(count<= card->max_recv_size); > >>> by > >>>> assert(count<= card->max_recv_size>0 ? card->max_recv_size : 256); > >>> > >>> And then everything worked as expected. > >> > >> The same concerns 'max_send_size'. > > Some more concerns! The max_*_size code was working, but now > we are making change to equate 256 = 0. Its not clear to me what is the > problem. > > > I would suggest that max_recv_size and max_send_size are always > 0, and > if using extended APDUs, could be > 256. > > The only place where 0 implies 256 is in a short APDU, and that is > handled by apdu.c as it builds the APDU to be sent and it is not using > the max_*_size > parameters. > > So I would like to suggest that we go back to 0.11 and look closer at > the original problem, and solve it without having to treat 0 == 256.
I have to agree, because the whole max_*_size magic is unnecessary altogether. For example max_recv_size is only limited by the size of the receive buffer. And this can vary. An excerpt from 7816-3: "Number Lr (length of response data) is the number of bytes present in the data field of the response APDU. [...] ***Number Lr shall be in the range zero to number Le.***" Therefore the only check required on sending APDUs is: Le <= sizeof(buf) If there is nobody, who is able to state a real requirement on max_recv_size, it could be removed from the code completely. On the other hand, the constraint max_send_size is actually required by some cards. But this could be handled in lower layers too. For example apdu.c could use chaining if Lc > max_send_size. > >> Attached diff that 'works for me' for the 'update_binary' operation. > > Thanks, now it should be changed in all places inside libopensc that made > > use of it, including muscle.h. > > > > About assert-s. I added the possibility to use --disable-assert when > > configuring OpenSC, this should be used by all binary distributions. > > Most of the asserts are from very early days of OpenSC and check for > > obvious errors like NULL pointers, that should be handled long before > > execution reaches those functions. > > > > If somebody finds the time, some of those asserts should be reviewed and > > higher level callers fixed so that such situations would be guaranteed not > > to happen. > > > > I'm not outright religious about asserts in "production code" but if they > > do exist in non-developer code, they should be somewhat helpful, so that > > there would be a theoretical chance of hitting an assert in real life, if > > certain (foreseeable/exotic) conditions are met. > > > > Some uses of assert (like "default: assert(0);") should not be used and > > most of the time a proper error code should be returned (SC_ERROR_INTERNAL? > > SC_ERROR_INCORRECT_PARAMETERS is already overloaded with different > > semantics (error in card command parameters and error in function > > parameters) > > > > > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
