Dead code, the law, and unintended consequences -

Dead code, the law, and unintended consequences


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.)

Another potential consequence of dead code is that an expert assessing the quality of your source code (e.g., in a product liability suit involving injury or death) may use as one basis of her opinion of poor quality that the source code she examined is overly-complex and riddled with commented out code and/or preprocessing directives. As you know, source code that is hard to read is harder than it needs to be to maintain. And, I think most experts would agree, code that is hard to read and maintain is more likely to contain bugs.

In such a scenario, your engineering team may come off as sloppy or incompetent to the jury, which is not exactly the first impression you want to make when your product is alleged to have caused injury or death. Note that overly-complex code also increases the cost of litigation — as both side's experts will need to spend more time reviewing the source code to understand it fully.

In a source code copyright (or copyleft) suit the mere presence ofanother party's source code may result be sufficient to proveinfringement — even if it is isn't actually built into the binary!Consider the risks of your code containing files or functions of opensource software that, by their mere existence in your source code,attaches an open source license to all of your proprietary code.

Bottom line advice: If source code is dead remove it. If you think youmight need to refer to that code again later, well that is what versioncontrol systems are for — make a searchable comment about what you'veremoved at such a checkin. Do this as soon as you are certain it won'tbe in a release version of your firmware.

Michael Barr is the author of three books and over 65 articles about embedded systems design, as well as a former editor-in-chief of Embedded Systems Programmingmagazine. Michael has also been a popular speaker, track chair, andmember of the advisory board at the Embedded Systems Conference for overa decade and is the president of Barr Group.He holds B.S. and M.S. degrees in electrical engineering and haslectured in the Department of Electrical and Computer Engineering at theUniversity of Maryland, from which he also earned an MBA, and theComputer Science Department of the Johns Hopkins University. He hasassisted in the design and implementation of products ranging fromsafety-critical medical devices to satellite TV receivers. You can reachhim via e-mail at or read more of what he has to say at his blog ().

7 thoughts on “Dead code, the law, and unintended consequences

  1. This helps to provides further justification for our coding standards, which disallow “dead” code. Thanks for the added ammunition, as it was an aspect I had not considered.

    Log in to Reply
  2. It's also fair to mention that for some consumers, such as the aviation world where there are strict rules concerning coding style and content, dead code is strictly VERBOTEN. Not a bad rule.

    Log in to Reply
  3. In the DO-178 world, #ifdef macros are not considered dead code. Since the the code is not compiled it is meaningless to consider the question “will not be executed” which presumes some non-zero probability of being executed.

    Log in to Reply
  4. The fact that consultants are paid by the either defendant or plaintiff should make the jury very wary of their testimony, at least if it were me on the jury. But engineers (or any college graduate) are rarely chosen for jury duty.

    Log in to Reply
  5. There is a class of code that is appropriately dead on one target and not on another due to #ifdefs. An example might a be product with two hardware versions having different external crystals but intended to use the same internal clock speed. There woul

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.