On 2012.12.11 00:32, Peter Stuge wrote: > Why is that? We maintain an array. Adding and testing array reallocation code is a PITA and development time is always super-limited, so the smart approach, instead of ignoring the more pressing matters to do "the right thing" (TM), is to just use a fixed array and find out if, in quite few years of usage, anybody who's using the library in a rational way hits the fixed limit and demonstrates the need for a realloc, chained list or whatever.
In this case, I would surmise that the the behaviour of having a limit that ensures that libusbx returns an error, so that a user can find out they probably shouldn't hammer the system with submissions that are too rapid in succession, is better than having to figure out why libusbx appears to be leaking memory or eventually ends up rendering a system inoperable by depleting fds or something. But feel free to fix that code in libusb, if that bothers you. Then I can decide if I want to pick your patch. Regards, /Pete ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
