sorry, it was in the line 2710

What card reader and what reader backend are you using (pcsc or ccid)?
Do you need this for supporting extended APDUs?

my card reader is Gemplus USB: Gempc-usb-sw, the reader backend is pcsc, i
using other pcsc software with this reader, it can support the function
correct, this feature is very important to me, because my card can support
long RSA key, such as 2048 bits, and GunGP cann't work with suck card.

It depends on the card. I don't have any card with 2k RSA keys here. The
change you suggested is likely to break other stuff. The correct way to return
longer results is by using GET RESPONSE. scdaemon will handle this
automatically but some cards may not allow for it. What card is that, can you
send me a sample?

the card is developed by me, i'm not sure whether i can send it to you. the
fault was caused by the out buffer is too samll for store the response data
and the status word, in my case the apdu send to card is: 00 C0 00 00 00,it
requires 258 (256+2) bytes to store the outter data, however the buffer
provided by the program is 256 byte, the pcsc back end will failed to handle
this apdu.

You are right. I recall that I had problems with some cards with Le=0 in the
GET RESPONSE but there is no actual check for it and thus the suggested change
can't harm.

Well, it would harm. It passes 258 to the PC/SC layer and that may choke on it.
I hesitate to change this given all the faulty cards out there. It would cost
me a serious amount of time to run regression tests on all the cards.

Why don't you just return 254 bytes and sw=6102 so that another GET_RESPONSE
will return the remaining 2 bytes.

When implementing extended APDUs we can implement the right thing without the
fear to break other apps.

are you means there some old pcsc driver will eject a out buffer with 258
bytes? as my experience, many pcsc driver will handle this correctly.

when i implment the whole card application, i can make sure every tpdu's
response data don't exceed 254 byte. but as you know, there some platform like
JAVA CARD and MULTOS, the develope maybe cann't cotrol the low level transmit.
and will make the card development difficult.

is it possible using config file or OS's environment variable to control
whether support the new feature (based on ATR or other thing), this will not
break the old card.

Yes.

However, I will risk it and release 2.0.1 with RESULTLEN increased to 258.

Thank you, I will look forward to it.

2.0.0 has been released.