I'll just add my opinion on parameter checking...
Anyone remember the "User Application Error" that old Windows versions used
to pop up? It was Microsoft's attempt to deflect blame for exactly the
same kind of crash in the Windows environment - most likely the user had
passed in a bad pointer (of course sometimes it was Microsoft's fault, but
not usually). The point here is if a program crashes in libusb, libusb
gets the blame. Doesn't matter if it was a null pointer from the
application, crash in libusb, libusb gets blamed.
Modern CPUs are so fast, there is no excuse not to check pointers or
handles for/to your own data structures. It's simply defensive
programming. So, in the example below, there is no excuse not to check
pdev. A pointer that's passed down into the OS untouched by libusb? No
need to check that as long as the OS doesn't do anything nasty (where nasty
is a fault rather than an invalid parameter, EFAULT or similar return).
Orin.
On Mon, May 7, 2012 at 8:01 PM, Xiaofan Chen <xiaof...@gmail.com> wrote:
> This may be good to be indexed in the libusbx mailing list as well.
>
> Whole thread:
>
> http://libusb.6.n5.nabble.com/FreeBSD-libusb-missing-libusb-get-descriptor-td5689243.html
>
> Regards,
> Xiaofan
>
>
> ---------- Forwarded message ----------
> From: Peter Stuge <pe...@stuge.se>
> Date: Mon, May 7, 2012 at 10:47 PM
> Subject: Re: FreeBSD libusb missing libusb_get_descriptor()
> To: libusb-de...@lists.sourceforge.net
>
>
> Xiaofan Chen wrote:
> > > Maybe you want to import some of those checks
> > > for the input parameters to this function.
> >
> > Thanks. Indeed the check may be good.
> >
> > Let's see Peter's view on this.
>
> Mh, I actually don't think so. I'll explain:
>
>
> > FreeBSD's implementation:
> > 296 int
> > 297 libusb_get_string_descriptor(libusb_device_handle *pdev,
> > 298 uint8_t desc_index, uint16_t langid, unsigned char *data,
> > 299 int length)
> > 300 {
> > 301 if (pdev == NULL || data == NULL || length < 1)
> > 302 return (LIBUSB_ERROR_INVALID_PARAM);
>
> Checking pdev and data is consistently not done in libusb - if you
> pass garbage then you get a crash. libusb wants to be thin.
>
> The USB 2.0 spec doesn't say that wLength=0 is invalid, so I think we
> should let that go down to the device if for whatever reason someone
> requests it.
>
>
> > 304 if (length > 65535)
> > 305 length = 65535;
>
> libusb-1.0 casts to uint16_t, which also truncates the value. The
> real error is that the API doesn't use uint16_t for the length, but
> that can't be fixed until next API.
>
>
> > 307 /* put some default data into the destination buffer */
> > 308 data[0] = 0;
>
> I'd rather not do this either, I don't think it's libusb's business
> to mess with the data, and 0 for descriptor length doesn't make so
> much sense.. The return value needs to be checked, and this is just
> one special case of the sync API, where the actual length is never
> available anyway. :\
>
>
> > 1369 int LIBUSB_CALL
> > libusb_get_string_descriptor_ascii(libusb_device_handle *dev,
> > 1370 uint8_t desc_index, unsigned char *data, int length);
>
> This function could very well need some love, and actually it would
> be nice to do something more intelligent than only support ASCII
> contents, such as libusb_get_string_descriptor_utf8(), but it could
> also be nice to offer an API which ties nicely into some or many
> different character set conversion libraries..
>
>
> //Peter
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> libusbx-devel mailing list
> libusbx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
