[C-safe-secure-studygroup] MISRA rule 2.3 - A project should not contain unused type declarations

Martin Sebor msebor at gmail.com
Tue Feb 21 20:03:24 UTC 2017


I can't make tomorrow's call so I forward my homework assignment
to the list.

Rule 2.3 - A project should not contain unused type declarations
seems pretty simple and straightforward (for the most part).
The rule text is just that, a single sentence.  The Rationale
makes sense, as does the Exception to exclude types in system
headers.  The only example of a violation shows a typedef defined
in a function.

The rule is marked Decidable which in MISRA means that an analyzer
must be able to decide in every case whether a piece of code does
or doesn't comply with it.

2.3 is also marked System, which means that an analyzer must
examine the whole program and cannot just base its decision on
analyzing one translation unit at a time.  This raises the
question of what our document should say about it.

GCC and compatible compilers have the -Wunused-local-typedefs
option that diagnose the violation in the example so there is
implementation experience with a subset of this rule outside
MISRA.  That suggests a rule like it is of value even outside
the environments targeted by the spec.

With that as background, there are some questions/issues with
the specification of the rule that I believe would need to be
addressed before it can be adopted.

1) The example (copied below) does not actually correspond to
the specification of the rule.

   int16_t unusedtype (void)
   {
     typedef int16_t local_type;   /* Non-compliant */

     return 67;
   }

According to C, a typedef "defines an identifier to be a typedef
name that denotes the type specified for the identifier."  Thus
the example shows a declaration of a name, not a one of a type.
(It makes no sense to declare a basic type like short.  A typedef
only defines a name/alias for an existing type.)  This may seem
like splitting hairs but the distinction is important to understand
exactly what is and isn't permitted by the rule.  Is the rule
intended to apply to typedefs or (also) to struct, union, and enum
tags?

I think question (1) can be settled by considering rule 2.4 -
A project should not contain unused tag declarations.  That is,
2.3 applies to typedefs alone (and would be more clearly and
correctly worded as: A project should not contain unused typedefs).
This should be corrected if the rule were to be adopted so that
the rule could stand on its own.

2) With (1) settled, there's a question of the meaning of the word
"unused."  Consider the following complete project:

    typedef struct List List;

    struct List { List *next; };

Here the typedef List is used to define the struct for which
the typedef is an alias.   So rule 2.3 doesn't seem to apply.
Similarly, the tag List in struct List is used in the defintion
of the typedef List.  and so rule 2.4 also doesn't apply. I suspect
this isn't MISRA's intent but if it were, I think a rule that would
better serve the purpose outlined by MISRA for 2.3 would be one that
did require a diagnostic for this example.  Since the terms "used"
and "unused" are pervasive among the MISRA rules their meaning
should be made clear if the rules were to be adopted.

3) One final consideration relating to 2.3 is about the exception.
It (reasonably) exempts typedefs in standard and third party headers
but it doesn't do the same for typedefs defined in the project's
own headers.  Expecting a large, modular project to define only
the set of names that are actually used by it seems exceedingly
restrictive.  This is especially so for typedefs that are used
conditionally, say in a particular data model (say ILP32). I don't
think such a rule would be helpful.

Incidentally, this also raises a question about the Decidability
of the rule.  Is a typedef that is used only conditionally (either
in a conditionally included block of code guarded by a preprocessor
conditional such as #if INT_MAX < LONG_MAX, or in a block guarded
by if (sizeof (int) < sizeof (long)) considered "unused" if the
condition is false?  What about one in a block guarded by
if (a < b) where a and b are variables whose exact values are
unknown but for which data flow analysis may be able to determine
that they satisfy the relation?  (More to the point, where do we
draw the line for Decidability and how do we specify it so as not
to rehash this question for every other rule?)

Martin



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