[C-safe-secure-studygroup] MISRA Rule 2.2: there shall be no dead code

Kostya Serebryany kcc at google.com
Wed Feb 22 00:10:26 UTC 2017


[can't easily copy-paste parts of text from the document, assuming you all
have the copy]
These are pages 49-50 of the PDF.
The rule is straightforward and useful, but important details & examples
are missing.

The idea is plain and simple: code w/o side effects should not be present
as it likely indicates an error. A typical mistake is a code like
   a + b;
or
   a == b;
which is most likely a typo and
  a = b;
was meant. ('+' is shift+'=')

The allowed exception is to do
  (void)expression
which is pretty bad.
I've seen lots of cases where (void)expr is used to suppress valid dead
code instances
or where the API nearly pushes developers to use this escape hatch.
E.g. I've seen these a lot:

    int res = expression;
    (void)res;   // res is used in assert, in release mode we get dead code
warnings
    assert(res);

It's unclear if
    int res = *MaybeNullPointer;
    (void)res;
should be left by the compiler in the binary.

It is unclear how to detect dead code in general and what level
of detection is expected to satisfy misra.
Do we expect  analysis at the scope of compilation unit, inlining,
cross-module inlining?
For example:

   void foo(int flag) {
       int res = expression;
       if (flag && res) { ... }
    }

is 'res = expression' dead?
What if the only call to foo is 'foo(0)'?
What if that call is in another compilation unit?

The document clearly states that a memory load operation is dead code if
the result is unused.
But It's  unclear if a division could be a part of dead code, e.g.
   unused = a / b;  // may cause SIGFPE and thus change the program
behavior

same for e.g, for memory allocation, which may cause arbitrary side
effects, such as termination,
huge slowdown, address space changes, etc.
   unused = calloc(1ULL << 34, 1);



--kcc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20170221/3ff5e453/attachment.html>


More information about the C-safe-secure-studygroup mailing list