McIntyre: Scanning for assembly code in Free Software packages

Posted Apr 2, 2013 21:15 UTC (Tue) by FranTaylor (guest, #80190)
In reply to: McIntyre: Scanning for assembly code in Free Software packages by Aliasundercover
Parent article: McIntyre: Scanning for assembly code in Free Software packages

Anything written in assembler is clearly "broke" with respect to portability, which is the criterion in question.

To put finer point on it, incomprehensible code that "just works" should be put high up on the list of things to FIX, not "leave alone".

Honestly your "old saw" about "leaving things alone" is just POOR ENGINEERING PRACTICE.

---

Programs must be written for people to read, and only incidentally for machines to execute.

- H. Abelson and G. Sussman (in "The Structure and Interpretation of Computer Programs)

McIntyre: Scanning for assembly code in Free Software packages

Posted Apr 2, 2013 21:24 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

who said that this code is "incomprehensible"?

But in any case, if you re-write incomprehensible code, you are almost guaranteed that the result is code that doesn't do the job that the original did, because you don't fully understand the problems that the code is solving.

You probably understand the more obvious problems, but the subtle problems and corner cases will bite you.

That doesn't mean that you should never re-write something, but rather than when you do so, you need to recognize that you aren't going to get it right in the first try, and you need to be sure that the value of having the new code (leaner/faster/better documented/etc) is greater than the effort to re-write the code AND then debug the code after it hits the real world (including whatever damage the bugs can do)

McIntyre: Scanning for assembly code in Free Software packages

Posted Apr 3, 2013 3:45 UTC (Wed) by rsidd (subscriber, #2582) [Link]

You are taking "incomprehensible" literally. No code is incomprehensible. But taking assembly code that takes an hour to understand, and replacing it with C code that takes 5 minutes to understand, is a win, especially if you are the maintainer (it may not be worth it if it's an obscure package and you're a distro packager).

McIntyre: Scanning for assembly code in Free Software packages

Posted Apr 2, 2013 22:13 UTC (Tue) by Aliasundercover (guest, #69009) [Link] (3 responses)

> Honestly your "old saw" about "leaving things alone" is just POOR ENGINEERING PRACTICE.

There is a reason why software has a reputation for mickey mouse engineering. Even the things that did once work break in the endless update churn. Other fields respect leaving working designs alone until there is a genuine need to change them and time to verify those changes are correct.

Even this field respected leaving working things alone before security paranoia set in. Now we have an endless arms race with the hackers and a new set of patches every time you look away. Only hack resistance is served while all other measures of quality suffer.

Since you liked my last old saw so much I have another for you. There is no such thing as portable software, only software that has been ported.

McIntyre: Scanning for assembly code in Free Software packages

Posted Apr 2, 2013 22:24 UTC (Tue) by xbobx (subscriber, #51363) [Link] (1 responses)

> > Honestly your "old saw" about "leaving things alone" is just POOR ENGINEERING PRACTICE.

> There is a reason why software has a reputation for mickey mouse engineering.

Both are true. In mechanical or civil engineering, just because a bridge hasn't fallen over yet doesn't mean that it doesn't need to be monitored for flaws and maintained to stay up to code. Then again, a perfectly good concrete bridge doesn't need to be replaced by a fancy new suspension bridge just because suspension bridges are all the rage nowadays.

Engineering is the practice of applying judgement to decide when the current solution is sufficient and can be left alone, or needs refinement and to what extent. Doing either extreme by default is going to bite you.

QotW

Posted Apr 3, 2013 20:56 UTC (Wed) by man_ls (guest, #15091) [Link]

Engineering is the practice of applying judgement to decide when the current solution is sufficient and can be left alone, or needs refinement and to what extent. Doing either extreme by default is going to bite you.

Good Quote of the Week, if you ask me.

McIntyre: Scanning for assembly code in Free Software packages

Posted Apr 3, 2013 8:57 UTC (Wed) by ssam (guest, #46587) [Link]

the new bugs you get in an update are because some change has unforeseen consequences. this probably happens a lot because software is complex with many interdependent parts, some of them more fragile than you would expect.

so modifying any code is potentially dangerous, and needs to be tested. translating asm to C may introduce a subtle behaviour change. but if the change is in a corner case, its quite possible that it was doing the wrong thing in asm and no one ever noticed.

maybe the asm version is fast because it does not check for alignment, or that something is non-zero (maybe poor examples). maybe when the asm was written all the data was aligned, and x was never zero, but that assumption might not always be true.

so replacing a fragile bit of asm with a robust bit of C might be a very good thing. (not that all asm is fragile, or all c is robust. but i am sure the compiler and static analysis tools can give you much better warnings for the C).