On Tuesday 08 March 2005 8:23 am, Alan Stern wrote: > Your use of the new is_in variable looks a little strange. It gets > assigned, used once,
OK, so a temp can be eliminated by hand as well as by letting gcc do it ... > then ignored for deciding the direction of control > transfers. Or to put it differently: for control transfers, uurb.endpoint is completely ignored in favor of the direction in the actual setup packet (which is what the peripheral will be using). Even though some folk might expect a (new!) fault to be reported when they don't match. > Why not instead handle the control transfer case directly at > the spot where is_in is defined (there's a perfect opportunity a few lines > down) and then use it consistently? I'm not sure what you're saying there. "Where it's defined" is not the same as "a few lines down". And almost by definition, a single use is consistent (with itself) ... > Also you could make things slightly > simpler if is_in stored the direction mask rather than a boolean flag. If GCC is optimizing out its single use, it shouldn't matter ... ;) - Dave > > Alan Stern > > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
