| Summary: | calcBorderPoints' calculations do not handle special cases | ||
|---|---|---|---|
| Product: | [Applications] kig | Reporter: | David E. Narvaez <david.narvaez> |
| Component: | general | Assignee: | Pino Toscano <pino> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ian.monroe, jpwhiting |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: | Fix to handle special cases using standard numeric limits | ||
Is anyone on top of this? The bug already hit my Sabayon Linux installation too (32 bits) so I expect it to be everywhere and there's still no comment on this bug. David E. Narvaez Well, will somebody ever take a look at this report? I'm a frequent Kig user and I need to know if there are plans to fix this annoying bug anytime soon (that is, in the course of the next 6 months) or if I should migrate to another better-supported application. David E. Narvaez Git commit c3372f4b29d4599a5447af53ed39645bcac5a535 by David E. Narváez. Committed on 25/08/2011 at 13:37. Pushed by narvaez into branch 'master'. Handle special cases when drawing lines in Kig Patch to fix bug 266497, by handling special cases when drawing a line in Kig using C++ standard limits. BUG: 266497 REVIEW: 102417 M +5 -4 misc/common.cpp http://commits.kde.org/kig/c3372f4b29d4599a5447af53ed39645bcac5a535 |
Created attachment 57316 [details] Fix to handle special cases using standard numeric limits Version: unspecified (using KDE 4.6.0) OS: Linux Checking calculations of variables left, right, top and bottom on the calcBorderPoints method in the file common.cpp I see there is no checking for divisions by zero and instead the handling of those special cases are left to the compiler and the C++ implementation. In my case, that lead to a bug when displaying the pop-up menu causing lines (displayed for the style selection) to be drawn annoyingly slow because NaN (the result from the division by zero) would always compare to false later in the calcBorderPoints method. I think letting the compiler/implementation deal with those special cases is risky, to say the least. An obvious fix is to check for equality before calculations, and assigning proper limits to the variables. The attached patch shows the svn diff of my fix with the working copy. David E. Narváez Reproducible: Sometimes