From there, the Helium system then replaces the original bit-rotted components with the re-optimized ones. The net result: Helium can improve the performance of certain Photoshop filters by 75 percent, and the performance of less optimized programs such as Microsoft Windows’ IrfanView by 400 to 500 percent.
“We’ve found that Helium can make updates in one day that would take human engineers upwards of three months,” says Amarasinghe. “A system like this can help companies make sure that the next generation of code is faster, and save them the trouble of putting 100 people on these sorts of problems.”
Source: Computer program fixes old code faster than expert engineers | MIT News
Having the ability to automatically fix bad code is like when they introduced auto focus on cameras to automatically fix bad focus or auto tunes to fix bad singing. The downside might be that development chooses to do less code reviews releasing more bad code into the wild relying on these automatic techniques to fix everything.
Here’s another article recently published by MIT News about this concept.
Remarkably, the system, dubbed CodePhage, doesn’t require access to the source code of the applications whose functionality it’s borrowing. Instead, it analyzes the applications’ execution and characterizes the types of security checks they perform. As a consequence, it can import checks from applications written in programming languages other than the one in which the program it’s repairing was written.
Source: Automatic bug repair | MIT News
As demonstrated, this vulnerability wasn’t a result of insufficient system testing; it was because of insufficient unit testing. Keith Ray himself wrote a “Testing on the Toilet”8 article, “Too Many Tests,”11 explaining how to break complex logic into small, testable functions to avoid a combinatorial explosion of inputs and still achieve coverage of critical corner cases (“equivalence class partitioning”). Given the complexity of the TLS algorithm, unit testing should be the first line of defense, not system testing. When six copies of the same algorithm exist, system testers are primed for failure.
via Finding More Than One Worm in the Apple – ACM Queue.
Here are the names and categories for the winners of the 22nd IOCCC:
via Who won the 22nd IOCCC.
IOCCC=International Obfuscated C Code Contest
The source for all the entries should compile and run. I liked this one: Most catty
horizontal_cat concatenates files horizontally and write the output to stdout. Each input file is padded with spaces on the right so that the original text alignments are preserved.
The goal of the contest is to write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil. Every year, we will propose a challenge to coders to solve a simple data processing problem, but with covert malicious behavior. Examples include miscounting votes, shaving money from financial transactions, or leaking information to an eavesdropper. The main goal, however, is to write source code that easily passes visual inspection by other programmers.
via The Underhanded C Contest.
Since I had one week before my next contract I decided to finish my “cycle of id”. After Doom, Doom Iphone, Quake1, Quake2, Wolfenstein iPhone and Doom3 I decided to read the last codebase I did not review yet:
idTech3 the 3D engine that powers Quake III and Quake Live.
via Quake 3 Source Code Review: Architecture.
I was particularly impressed by :
- The virtual machines system and the associated toolchain that altogether account for 30% of the code released. Under this perspective idTech3 is a mini operating system providing system calls to three processes.
- The elegant network system based on snapshots and memory introspection.