Peter Wu wrote: > > This Ralink device returns bogus values for some string descriptors > (iSerial, iInterface). The bDescriptorType and everything following that > changes every time, but at least the first byte stays consistently 0. > The USB 2.0 spec (9.6.7 String) does not define the behavior for > bLengths 0 and 1, so let's assume that string descriptors following that > are completely junk. >
I'm not sure I agree with this philosophy. As you say, the spec does not define the behavior, so why should the library impose a penalty? It seems to me that libusb_get_string_descriptor ought to return exactly what it got. I do agree that the convenience wrapper (libusb_get_string_descriptor_ascii) can have a more sophisticated policy, but I don't think you should be lying in the lower-level interface. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
