Re: libusb & PATH_MAX

[Samuel Thibault <sthibault@debian.org>]

Carl Fredrik Hammar, le Mon 18 May 2009 15:07:49 +0200, a écrit :
> Hi,
> 
> On Sun, May 17, 2009 at 09:57:26PM +0200, Samuel Thibault wrote:
> > Carl Fredrik Hammar, le Sun 17 May 2009 21:48:01 +0200, a écrit :
> > > On Sun, May 17, 2009 at 09:23:38PM +0200, Samuel Thibault wrote:
> > > > Carl Fredrik Hammar, le Sun 17 May 2009 21:18:57 +0200, a écrit :
> > > > > In that case we could just remove the PATH_MAX.
> > > > 
> > > > That'd prevent from actually providing USB someday.
> > > 
> > > Yes, but I think we should wait with a real solution until we actually
> > > have USB support and can test it.  In the mean time I think its best
> > > to have a non-solution that breaks loudly as soon we do have USB.
> > 
> > I don't understand your reasoning.  What do you precisely mean by
> > 'remove the PATH_MAX'?  Since you were talking about applications not
> > even using the result I assumed you meant something like
> > 
> > 	char filename[1];
> 
> This is precisely what I meant.
> 
> > but then once compiled this way, these applications won't work even if
> > after that we provide a libusb that works.
> 
> 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.

> Using malloced memory is the ideal solution, but potentially a lot of
> work.

And as I said, it may break.

> When we actually have USB support, we will have more motivation
> to implement it and the ability to actually test to see if it works.
> Of course, the apps will need to be recompiled once it's in place.

Not necessarily. If we define LIBUSB_PATH_MAX, we can just keep them the
way they're already compiled.

> Would this be a big problem?

We can name the libusb another way to express the different ABI and not
miss any applications that isn't recompiled with the new ABI.

> 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?

Samuel