Re: usb_make_path()

[Alexey Klimov <klimov.linux@gmail.com>]

(added linux-media mail-list)

Hello to all

On Wed, 2009-01-21 at 21:44 +0100, Thierry Merle wrote:
> Hi Douglas,
> Douglas Schilling Landgraf a écrit :
> > Hello friends,
> > 
> >      Since you sent patches to linux-media for usb_make_path changes, I
> > would like to make a question for you. Should we check for
> > return of usb_make_path as a good programming practice?
> > 
> > static inline int usb_make_path(struct usb_device *dev, char *buf,
> > size_t size)
> > 
> > I didn't see this check in your patches.
> > 
> I saw that the return code was checked in some other v4l sources, but I preferred to ignore the return value like done in many other drivers (see http://lxr.falinux.com/ident?i=usb_make_path)
> I know it is bad but for failing this function fails if the buffer is to small to copy the complete usb path.
> Nevertheless it uses snprintf that truncates safely the string if needed.
> What to do if this function fails? I did not see anything better, so ignoring the return code seemed to be the best.

usb_make_path returns -1 if sizeof buffer is smaler than path (no device
or hardware troubles). Bus_info is 32 byte and usb path looks like:
"usb-%s-%s", dev->bus->bus_name, dev->devpath (from usb.h). I failed
trying to find size of bus_name, but maximum size of dev->devpath is 16
chars.

So, i'm confused about two things:
- as this information goes to userspace, will userpace feel bad that
trucated string will be delivered? And do v4l-subsystem care enough to
provide complete usb-path?
- will it happened one day that usb_make_path returns -1 and we care?

I don't have ideas about first thing.
In case we care to provide full usb-path - may be check for returned
value should be placed, print message and ask user, for example:
"usb_make_path error! Please send message to linux-media maillist".
In case of many reports size of bus_info[32] can be increased.

By other side, if this all is really important? It's right that ignoring
returned value is safe.


-- 
Best regards, Klimov Alexey