[C-safe-secure-studygroup] Unreachable v Dead Code

[Martin Sebor]

On 03/20/2017 12:33 AM, Andrew Banks wrote:
> Date: Fri, 17 Mar 2017 09:59:55 -0400
> From: "Wheeler, David A" <dwheeler at ida.org>
> To: C Safety and Security Study Group Discussion
> 	<c-safe-secure-studygroup at lists.trustable.io>
> Subject: Re: [C-safe-secure-studygroup] Unreachable v Dead Code
>
> 	1. In many cases software typically has code that is not used for a specific environment.
> 	E.G., in #idef BIG_ENDIAN  ... #else ... #endif, only part is used in a specific environment.
> 	So by "dead code" I presume we mean "code that cannot possibly be used in any environment".
>
> Code that is conditionally compiled out is not 'Dead Code' (or unreachable, or infeasible) or anything else, as in that build configuration it does not exist!

I agree.  In my experience, the usual meaning of Dead Code is code
that is compiled but that is either not reachable or has no effect
(see for example Wikipedia, the deprecated CERT MSC07-C, or CWE-561
although the Wikipedia definition has the same problem as MISRA 2.2,
namely stating that dead code is executed).

There are two flavors of the idiom described above in common use
in C programs.  The one above (i.e., what in the C standard is
referred to as conditional inclusion), and one that involves
the if statement with a constant controlling expression.

The latter is often used with sizeof expressions (e.g, if (sizeof
(int) == sizeof (long)), etc.) in preference to something like #if
INT_MAX == LONG_MAX, typically because there is no macro that can
express the constraint, or because of the benefit of compiling
the code (and checking it for errors) regardless of the constraint.

Somewhat ironically, even though they are essentially equivalent,
the latter form is safer but considered Dead Code (and subject
to the rule) while the former is not.

>
> 	2. This must ONLY apply to the software written for a particular project.
> 	Software systems in many cases are mostly libraries, with a little custom code to glue them together.
>
> Libraries are not (usually!) subject to static analysis at the source code level within a project... and the linker only (usually!) includes those functions that are required.

True.  The downside, of course, is a compromised efficacy of
the analysis.

Martin