Dead code can have unintended legal consequences. Here's what shows up in court.
Dead code is source code that is not executed in the final system. It comes in two forms. First, there is dead code that is commented out or removed via #ifdef's. That dead code has no corresponding form in the binary. Other dead code is present in the binary but cannot be or is never invoked. Either way, dead code is a vestige or unnecessary part of the product.
One of the places I have seen a lot of dead code is in my work as an expert witness. And I've observed that the presence of dead code can have unintended legal consequences. In at least one case I was involved in, it's likely that strings in certain dead code in the binary was a major cause of a lawsuit being brought against a maker of embedded system products. I've also observed several scenarios in which dead code (at least in part) heightened the probability of a loss in court.
One way that dead code can increases the probability of a loss in court is if the dead code implements part (or all) of a patented algorithm. When a patent infringement suit is brought against your company, one or more versions of your source code -- when potentially relevant -- must be produced to the other side's legal team. The patent owner's expert(s) will pore over this source code for many hours, seeking to identify portions of the code that implement each part of the algorithm. If one of those parts is implemented in dead code that becomes part of the binary, the product may still infringe an asserted claim of the patent -- even if it is never invoked. (I'm not a lawyer and not sure if dead code does legally infringe, but consider it at least possible that neither side's expert will notice it is dead or that the judge or jury won't be convinced by a dead code defense.)
Micheal Barr's blog (originally published on Embedded.com in May 2013) continues here. He is delivering the keynote address at EE Live! on Tuesday, April 1, 2014.
— Michael Barr is the author of three books and more than 65 articles about embedded systems design, as well as a former editor in chief of Embedded Systems Programming magazine. Michael has also been a popular speaker, track chair, and member of the advisory board at the Embedded Systems Conference for over a decade and is the president of Barr Group.