usb_make_path()
(added linux-media mail-list)
Hello to all
Quoted 11 lines · Thierry Merle
Hi Douglas,
Quoted 9 lines · Douglas Schilling Landgraf
Hello friends,
Since you sent patches to linux-media for
usb_make_pathchanges, I
would like to make a question for you. Should we check for return ofusb_make_pathas a good programming practice?static inline int
usb_make_path(struct usb_device *dev, char *buf, size_t size)
Quoted 6 lines
Quoted 2 lines
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.
Signature · 1 line
Best regards, Klimov Alexey