On Fri, Jul 6, 2012 at 9:44 AM, Keith Packard <[email protected]> wrote: > Torsten Kaiser <[email protected]> writes: > >> My guess would be, that these bits where reserved in the spec and >> should never been set. > > These bits come from external sources, and often buggy ones at that. We
Yes, because buggy devices can trigger this, I like to see it fixed and not only making gcc no longer notice this. > should probably just compute the index and skip it if it's out of There was an earlier patch that did that: http://lists.x.org/archives/xorg-devel/2011-November/027176.html But I found that adding these calculations to the loop made it rather difficult to read. The solution with the dummy entries looked better to me, because its obvious what they are at the first glance. > range. Sending a mode of all zeros along to the rest of the server is > likely to cause chaos (and divide-by-zero errors). Thats why I added "if (EstIIIModes[m].w)" into the loop to skip over them, even if the device sends the strange bits to enable them. Just the current code could cause chaos, if these bits ever get enabled, because it would try to use whatever comes after EstIIIModes as mode information. >> The two issues where just located so near each other, that I fixed >> them in one go. > > It is nice to have separate patches anyways; one per bug. That can make > back-porting changes easier to manage. Not arguing with that. Thats why I immediately redid patch(es) after your request. I just couldn't resist slipping the single = into the original patch, after I noticed the second bug. ;-) Torsten _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
