Re: Possible data truncation on receive in 1.8.14
Ludovic Rousseau <[email protected]>
| Newsgroups | gmane.comp.lib.muscle |
|---|---|
| Message-ID | <CAGstE8CQQU6rFOCLoGFYmCveJGLCtAT3F1G-089cSb-cpmYVxw@mail.gmail.com> |
2015-11-13 15:35 GMT+01:00 Marcin Cieslak <[email protected]>: > On Fri, 13 Nov 2015, Ludovic Rousseau wrote: > > > > The problem turns out is that the receive buffer size > > > is now 65548 bytes on my platform, > > > and my configuration seem to return only > > > 12 bytes with such a large buffer. > > > > > > > I don't know how a bigger buffer could have a truncation as effect. > > > > Where exactly does the truncation occurs? > > This happens when passing data to CT API: > > char CT_data(unsigned short ctn, /* Terminal Number */ > unsigned char *dad, /* Destination */ > unsigned char *sad, /* Source */ > unsigned short lc, /* Length of command */ > unsigned char *cmd, /* Command/Data Buffer */ > unsigned short *lr, /* Length of Response */ > unsigned char *rsp /* Response */ > > The supplied buffer length on my system, 65548 (hex 0x1000c) gets > downcast to (unsigned short), which is 12. > > CT-API will not accept a buffer longer than 64KB. (No wonder given its > origins). > Maybe you can fix CT-API API to use "unsigned int" for a buffer size instead of "unsigned short". > I wish I wouldn't need to use that but my CCID PCMCIA reader is otherwise > not supported. > I don't think it is a CCID reader if it uses PCMCIA. CCID is for USB (or USB over ExpressCard). > (By the way, for some broken application I have to "#define > DISABLE_ON_DEMAND_POWER_ON" > but that's another story). > Yes, another story. Please do not mix bug reports :-) Bye -- Dr. Ludovic Rousseau _______________________________________________ Pcsclite-muscle mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle