Slashdot Mirror
KDE Bug Fixed After 13 Years (kate-editor.org)
About 50 KDE developers met this week in the Swiss Alps for the annual Randa Meetings, "seven days of intense in-person work, pushing KDE technologies forward and discussing how to address the next-generation demands for software systems." Christoph Cullmann, who maintains the Kate editor, blogs that during this year's sprint, they finally fixed a 13-year-old bug. He'd filed the bug report himself -- back in 2003 -- and writes that over the next 13 years, no one ever found the time to fix it. (Even though the bug received 333 "importance" votes...) After finally being marked Resolved, the bug's tracking page at KDE.org began receiving additional comments marveling at how much time had passed.
Just think, when this bug was first reported:
-- The current Linux Kernel was 2.6.31...
-- Windows XP was the most current desktop verison. Vista was still 3 years away.
-- Top 2 Linux verions? Mandrake and Redhat (Fedora wouldn't be released for another 2 months, Ubuntu's first was more than a year away.)
-- The current Linux Kernel was 2.6.31...
-- Windows XP was the most current desktop verison. Vista was still 3 years away.
-- Top 2 Linux verions? Mandrake and Redhat (Fedora wouldn't be released for another 2 months, Ubuntu's first was more than a year away.)
I fixed this bug a month after it was first announced, but when submitting it I was told that other parties didn't want the bug fixed, and that I should forget about it for my own safety. The more you know.
They've finally corrected it to "CDE"
...discussing how to address the next-generation demands for software systems....
Hopefully, the future KDE will be a bit more (OK, a lot more) efficient, and less bloaty.
If we're all feeling nostalgic, this should do the trick:
The Linux Backdoor Attempt of 2003
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;
Other issues back in 2003 were burning up the Linux development intertubes.
The mind behind Linux
The following is my idea of good taste (since the 1980s), whenever a comparison involves a constant term:
if ((options == (__WCLONE|__WALL)) && (0 = current->uid))
retval = -EINVAL;
This does not achieve root. It won't even compile.
Typical KDE
About 50 KDE developers met this week in the Swiss Alps....
Reeeaaaallllly?
Throw in some hookers and blow, and I'll sign up to test, do your laundry, wipe your ass, and even .... WRITE DOCUMENTATION!
When it was submitted apple still had a 1 button mouse.
Some drink at the fountain of knowledge. Others just gargle.
And slashdot doesn't even try to describe the bug in the summary.
Bad code is ugly code. There's zero reason not to swap the expression into something safer except "that's the way I think it in my head". Turn your head around.
Play Command HQ online
One of the problems with software development is that people like adding features but they won't invest the time to crush every last bug. As a result, a bug could come from any number of layers in the API you are using so it's considered to be "impossible" to make perfect software. My fellow software developers, you really need to up your game! :(
Anons need not reply. Questions end with a question mark.
I'll just leave this here: https://www.jwz.org/doc/cadt.html
And I bet in the end it took 10 minutes to do the job. This is nothing but a testament of wrong priorities of project leadership. Fix the stuff that people are already using rather than cramming in more broken features that users did fine without so far. I guess users are fine with subpar quality even in FOSS projects.
" 8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.
My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it. [...] But the key point is that both parts of the process (finding and fixing) tend to happen rapidly." ESR CatB
So, 13 years, right? And is not the first time. Holes in hipervisors for 12 years, heartbleed, ...
I've said it before and I'll say it again:
One does not only need "Eyes". One needs QUALIFIED AND MOTIVATED EYES, along with adequated Q&A Process to tame the bugs.
*** Suerte a todos y Feliz dia!
Why not:
if (((__WCLONE|__WALL) == options) && (0 = current->uid))
retval = -EINVAL;
?
I don't think many compilers will emit a warning on that code because the assignment is surrounded by parenthesis.
"First they came for the slanderers and i said nothing."
"Windows XP was the most current desktop verison. Vista was still 3 years away." I suggest you to take some more time and write "version" correctly
Open Source:
Closed Source|Commercial:
Both Open Source and Closed Source suffer from project abandonment.
It does seem though that Closed Source gets away with ignoring usability feature requests, and feature requests in generall
It's pretty much up to the Dev.
1) WinRar -> constantly developed and updated. Very usable.
2) Total Commander -> rarely developed. Curmudgeon single developer that hasn't implemented a single usability UI request in 10 years.
3) EmEditor -> frequent (small updates). Possibly single developer, that hasn't implemented a single usability UI request in 10 years.
Most of KDE is GPLed.
.dnuora daeh ruoy nruT ."daeh ym ni ti kniht I yaw eht s'taht" tpecxe refas gnihtemos otni noisserpxe eht paws ot ton nosaer orez s'erehT .edoc ylgu si edoc daB
You say it like "what's in your head" is some small insignificant function of source code. There's a reason it's not in binary like a computer would prefer, it's so we humans can work on it. Whenever you're given a problem like "solve for x" everybody in western countries ends up with "x = [value]" not "[value] = x". Sure you could learn to read backwards too, like the text above but it's extremely annoying unless you force yourself to learn it. Personally I'd rather have banned the "=" operator and made it ":=" for assignment, "==" for comparison. You could keep the complex operators like "+=" etc. but not just the equal sign. That we don't use for equality, I mean it should be obvious something's not all that smart here.
Live today, because you never know what tomorrow brings
There's zero reason not to swap the expression into something safer except "that's the way I think it in my head".
Except... your little trick only works in a very limited amount of cases, when comparing against constants. If you compare two variables, then it doesn't help swapping them around. It promotes a code style that creates a false sense of security.
My code style is to never use assignments in a boolean condition (if, while), but to put them on a separate line. And then have the compiler throw an error if I accidentally type one less equals char in a boolean comparison. That results in much safer code than your half trick that doesn't really work.
The following is my idea of good taste (since the 1980s), whenever a comparison involves a constant term: if ((options == (__WCLONE|__WALL)) && (0 = current->uid))
And when it doesn't involve a constant term, what then?
Better to make sure your compiler warns on assignments in conditionals (and maybe even turn warnings into errors), then write in comparisons in whatever order reads most naturally.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I have posted who knows how many bugs to the KDE bug tracking system. All legitimate and very bad bugs (I don't report minor stuff) with detailed intructions on how to reproduce and often how to fix the bug. All I get from the devs is that they can't recreate it(*) or pure silence.
(*) Which is a joke because I know they're just too lazy to even try. If I'm reporting a bug you can be damn well sure it exists because I test and retest on multiple clean installs on various hardware. It's what I do for a living. KDE is infected to the core with this lazy attitude.
Alternatively, learn to pay attention to -Wall.
I completely agree, and do the same thing. Assignments inside a conditional statement are horrendous, because it's not immediately clear whether the developer intended to make an assignment or a comparison. Moreover, the result of an assignment isn't as immediately obvious to anyone reading the code. It's one of the shittier "features" of C.
I've never understood people that try to shove as much shit as possible in a single line of code. It generally doesn't compile to more efficient machine code at all, and just makes it more difficult to parse by a human reader, which many developers underestimate the importance of. Just the other day I realized I'd been bit by a precedence bug when I was "sure" that I knew the correct precedence, only I didn't. It's just not worth being "clever". Boring, obvious code is the best code, for a variety of reasons.
Irony: Agile development has too much intertia to be abandoned now.
Boring, obvious code is the best code, for a variety of reasons.
That's why I choose... COBOL.
I kid, I kid.
But then 'real programmers' don't need hand-holding where others would delegate responsibility for such low level gotchas to a compiler. :)
So many of the posters here are missing the context. At the time that bug was found, compilers, especially GCC, did not warn about assignments in conditional statements. Now, they do*.
* experience with GCC and clang. Both force double parentheses to indicate assignment is actually desired.
At the time that bug was found, compilers did not warn. Now, both GCC and clang will warn unless you enclose the assignment in two sets of parentheses.
If someone is too inflexible to solve their algebra problems with [value] = x, then they probably should not take up programming as a career.
Play Command HQ online