Uri Lublin wrote:
> > Commit 4cccbed825fe1dc13812 removes the possibility to choose between
> > DYNAMIC_FDS and not, and makes the previously optional behavior
> > enforced, so the code in !defined() was likely removed on purpose.
> > (DYNAMIC_FDS was on by default, so it has always been used on Windows
> > since the code was introduced. There have been no comments on that
> > code either way, however.)
> >
> > I'm not sure if DYNAMIC_FDS or not DYNAMIC_FDS is more correct. The
> > comment documenting the define wasn't completely clear to me. Awesome
> > if you can help clear this up?
> 
> It seems DYNAMIC_FDS was not defined by default (at the time of above 
> commit).

You are of course absolutely right. I may have been confused by the
unrelated AUTO_CLAIM changes in the same commit. Sorry!

I've included the commit in libusb.git with an attempt at clarifying
the commit message.

Did this cause a problem for you when using the library on Windows,
or did you rather discover it through static analysis?

Is the worst case that a new transfer would never time out, if no
timeout was given when calling the event handling thread, and 0
transfers were in flight? This would be a rather serious bug. :\

Would the transfer still complete in this case, or does the bug also
affect notification of completion?


> Removing both defined and !defined blocks is inconsistent (even if 
> DYNAMIC_FDS was defined before that commit).

Yes absolutely. Thanks for looking at this!


//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

Reply via email to