[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libusb & PATH_MAX



Carl Fredrik Hammar, le Fri 22 May 2009 14:43:39 +0200, a écrit :
> On Tue, May 19, 2009 at 12:19:10AM +0200, Samuel Thibault wrote:
> > Carl Fredrik Hammar, le Mon 18 May 2009 15:07:49 +0200, a écrit :
> > > 
> > > A similar problem happens when defining LIBUSB_PATH_MAX, but apps will
> > > only break when paths longer than it are encountered.  Until that happens
> > > it, this limitation might go unnoticed.
> > 
> > Yes.  And that might never happen so we'd not have to recompile them.
> 
> Well the same thing could be said for simply defining PATH_MAX and that
> has never been considered an acceptable solution AFAICT.

Yes, because in the PATH_MAX case applications can be fixed into not
using PATH_MAX.  In the libusb1 case, they can not.

> The mitigating factors in this case would be that it's an interim
> solution until libusb2 is used, and that USB device paths are expected
> to have short well defined paths, e.g. `/dev/usb/foo', or whatever.

Yes.

> > > If that's the case, then your suggestion of using char *filenname instead
> > > would be supperior.  Since only apps using sizeof(filename) will need
> > > to be fixed and recompiled.
> > 
> > But how to detect them?
> 
> Since you asked, I'm guessing you can't just grep for it...

You'd have to grep the entire archive, as packages might sometimes rely
on build-deps depending on libusb.

> But why not wait until they actually break?

Depending on the solution we adopt, the break may be memory overflows,
which are hard to understand where they come from. Here, the filename
string could in theory be 2 bytes long, and thus the application using
sizeof(filename) would overflow. We can make sure the filename is at
least sizeof(void*) though.

Samuel


Reply to: