embedded software boot camp

Dead Code, the Law, and Unintended Consequences

Wednesday, February 6th, 2013 by Michael Barr

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 is 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 have 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 of another party’s source code may result be sufficient to prove infringement–even if it is isn’t actually built into the binary! Consider the risks of your code containing files or functions of open source 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 you might need to refer to that code again later, well that is what version control systems are for–make a searchable comment about what you’ve removed at such a checkin. Do this as soon as you are certain it won’t be in a release version of your firmware.

Tags: , , , , , ,

5 Responses to “Dead Code, the Law, and Unintended Consequences”

  1. Rod Gullickson says:

    Hi Michael,

    You refer to the liability dangers of another parties source code in your code, does that apply to code that may exist in any version control software that we maintain, regardless of whether the code is in the shipped product?


    • Michael Barr says:

      It sounds like you are hypothesizing that the 3rd party source was never part of a released product’s build code but might be present in the version control repository. Obviously, I am not a lawyer. But the only way I am aware that could be problematic is if the same 3rd party was bringing suit and accused some other part of your code of being derived from theirs. That you once had their code could help them establish “access”, which could weaken your counter argument of independent discovery of the alleged derivative.

  2. James Hunt says:

    Dear Michael,

    The points you make are good ones, but one should clarify what dead code is. There are cases where code is in a binary, but it is not used in the system. The use of object oriented technology and the use of standard libraries can both be sources of this kind of code. Some certification standards, such as DO-178C and DO-278A recognize this. They differentiate between dead code, code that is not executed and has not requirements, and deactivated code, code that is not executed but is intentionally not used in a particular system. The rationale for this is that it is often harder to safely remove such code then to ensure that it is not used. In any case, this deactivated code must be planned for, have requirements, and have a full set of unit tests. Of course, whatever one can safely remove, should be removed. Smarter linking technology can help here.


    • kiran says:

      Kiran and chandru (BAeHAL software ltd bangalore),

      Yes i completely agree with James because as per DO178B safety critical software development guideline document Terms “Dead code” and “Deactivated Code” have distinct meanings:

      Dead code : Dead code is source code (and it is a part of binary code) that is not executed in the final system and it will be not having traceability to any requirements (one can say unintentional code).

      Deactivated code: code which is commented out or removed via #ifdef’s (it is not a part of final binary code) and it will be having traceability to its low level requirements (its a intentional code and it can be activated in some configurations through hardware traps for debugging or other purposes)

  3. Subramanian R says:

    This article has given me a good insight into embedded code and code structure in general. Can you please recommend an excellent book which provides guidance on good embedded software architecture and design?



Leave a Reply