A program’s “hidden feature” wreaks havoc in critical codebases

It all began last friday, when code testers at an important software firm began reporting incredibly good performance on modules that were expected to be shitty-but-elegant bulks of dinamically-typed objects interacting through dynamically-bound method calls to dynamically-loaded libraries spread throughout the disk. The substandard desktop PCs that were supposed to crunch through the code in endless hours well within the weekend just bleeped their correct outputs in no time. "We just followed the procedure: check out the code, build it, launch the test suite, report bugs," a tester told us, "but we never came to the last phase, no bugs showed out," he added with an irrepressible shiver. It was a thorough violation of the procedure, and the bug-tracking system would not let the testers out without reporting at least one deadly bug: "Most of us just cut it short by reporting 'Could not see the hourglass cursor', but I stayed at my desk for all the weekend, until system programmers removed the deadlock by shutting down the bug-tracking server. I was just mildly dehydrated, but I was able to flee to the toilet on my own legs."

A programmer, who asked to have his/her/its words scrambled in order to protect his/her/its anonymity, reports: "Wehn we looekd at teh cdoe, on mnoday mroning, we cuold not rceongise any line of it. Our craefluly cfarted acrhicetture was gone, rpelaecd by a neat and rdeaable set of aarrys, lists and pnoitres. How cuold taht be?" Soon thereafter, similar reports began to leak out of many software houses throughout the world.

Apparently, only a handful of projects, most notably the Linux and Windows operating systems, had not been harmed at all. Soon, an efficient pattern-matching algorithm (which, until friday, was well known as a stubborn coredumper) found out the common trait that all affected projects shared: they all used the GIT source code manager.

"We're going to sue the GIT people, as sure as hell! We're not supposed to sell perfect application suites: who would ever buy a 2.0 upgrade to a perfect program," reports a worried IBM spokesman.

A GIT spokesperson (guess who's the guy and who's the gal) initially refused to have her words recorded, but finally accepted when the reporter switched his recorder's encoding from "MP3" to "OGG": "You know, we aim at maximum efficiency and portability, and our policy only allows for C code. When we discussed about whether GIT should accept or refuse to manage projects written in other languages, we reached a very satisfying tradeoff solution: GIT would translate all user projects into K&R C upon committing, while the checkout procedure would retranslate them in the original language before returning them to the user, so that nobody would notice, and we could proudly claim that GIT was pure C in all aspects." Apparently, the checkout retranslation module was overwritten by an overzealous bzero() call with a series of NOPs, and many programmers found their work translated into optimized and surprisingly readable C code.

"We already had a glimpse of the problem last year," the spokesperson admits, "when some Word documents were returned as GROFF pages, however it was far too easy to blame Word for messing up its own files."

Programmers need not worry too much: the bug in the checkout routine has been fixed, and now C++, Java and C# projects are handled "in the usual Garbage-in, Garbage-out fashion," as Linus Torvalds shouted to us when asked about the problem. Apparently, Objective-C projects never suffered: "yup, that language cannot simply be straightened out, it's beyond all efficiency hopes. We just return an empty project: we found out that 98% Mac OS X projects are just tutorials half worked-through and then abandoned, so the programmer actually benefits from having to restart from scratch."