Sounds good then. Thank Denis for your feedback! Nicolas
Le mercredi 25 juin 2008 ? 23:25 -0700, Dennis Lou a ?crit : > FYI, I managed to scrape together a spare machine for testing and the patch > works fine here. > > -Dennis > > ----- Original Message ---- > From: Sam Varshavchik <mrsam at courier-mta.com> > To: Dennis Lou <dlou99 at yahoo.com> > Cc: Nicolas <nicolas.martin at freesurf.fr>; mrsam-guest <mrsam-guest at > alioth.debian.org>; sane-devel <sane-devel at lists.alioth.debian.org> > Sent: Wednesday, June 25, 2008 3:20:22 PM > Subject: Re: [sane-devel] Problem with libusb and 64 bits 2.6.25 kernel > > Dennis Lou writes: > > > The way I see it, Sam's buffer overflow concern is predicated on a > > misbehaving device. I haven't witnessed it but it is possible given that > > we're reverse engineering things rather than working from a formal spec. > > Nicolas' buffer overflow concern is predicated on a misbehaving usb stack. > > It's also possible, but probably less likely than Sam's concern. Which > > to implement depends on how paranoid you are about the behavior of the > > device and libusb. > > Clarification: my patch is needed to fix the following bug, referenced > earlier in the thread: > > >>> Hi Dennis, > >>> > >>> A bug was opened a while back by Sam Varshavchik, concerning the pixma > >>> backend for Canon ImageClass MF-4270, when compiled and used on a 64 > >>> bits platform (no issue so far on 32 bits), details are given here: > >>> > >>> https://alioth.debian.org/tracker/?group_id=30186&atid=410366&func=detail&aid=310861 > > The original code issues a read request to libusb for more bytes than > actually expected, and, apparently, on some hardware that causes a USB > timeout, with Various Bad Things?, as I described in the bug. Besides a > single scan now taking ~30 minutes, the resulting pnm is corrupted. > > By changing the code not to ask to read more than what's expected, that > fixes both the original bug, and the overflow problem. > > >