Software Development for Professionals
PC-Lint for C/C++ V9.0

PC-Lint / FlexeLint
MISRA Standard

Statische Analyse von C/C++ Quellcode.

Hersteller: Gimpel Software

Weitere Infos:   Features   Liste aller Meldungen

Einhaltung des MISRA C Standards mit PC-Lint / FlexeLint

Die Organisation MISRA (Motor Industrie Software Reliability Association) hat in verschiedenen Publikationen Richtlinien zur Programmierung von sicherheitskritischen Anwendungen mit C und C++ veröffentlicht. Ziel ist es damit unsichere C/C++ Konstrukte und unsichere Ausdrücke zu vermeiden.

Mit PC-Lint / FlexeLint kann die Einhaltung der MISRA Programmierrichtlinien garantiert und die Qualität Ihres C/C++ Quellcodes entscheidend verbessert werden. Und das zu einem erstaunlich günstigen Preis!

PC-Lint / FlexeLint unterstützt den aktuellen Standard nach MISRA C:2012, sowie auch die älteren Richtlinien nach MISRA C++:2008, MISRA C:2004 und MISRA C:1998.

PC-Lint / FlexeLint Meldungen nach MISRA C:2012


Meldungen im Bereich von 9000 - 9999 sind für MISRA C:2012 reserviert.

9001 Octal constant used -- An octal constant appears in the code. Octal constants may be inadvertently interpreted by engineers as decimal values. This message is not issued for a constant zero written as a single digit.
9003 could define variable 'Symbol' at block scope -- A variable was declared at global scope but only utilized within one function. Moving the declaration of this variable to that function reduces the chance the variable will be used incorrectly.
9004 object/function 'Symbol' previously declared -- The named symbol was declared in multiple locations, not counting the point of definition for that symbol. Declaring a symbol in one location and in one file helps to ensure consistency between declaration and definition as well as avoiding the risk of conflicting defintions across modules.
9005 attempt to cast away const/volatile from a pointer or reference -- A cast attempted to remove the qualifiers from an object to which a pointer points or a reference refers. Doing so can result in undesired or unexpected modification of the object in question and may result in an exception being thrown.
9006 'sizeof' used on expression with side effect -- If the operand of the sizeof operator is an expression, it is not usually evaluated. Attempting to apply sizeof to such an expression can result, therefore, in code one expects to be evaluated actually not being evaluated and the side-effects not taking place.
9007 side effects on right hand of logical operator, 'String' -- The right hand side of the || and && operators is evaluated only if the left hand side evaluates to a certain value. Consequently, code which expects the right hand side to be evaluated regardless of the left hand side can produce unanticipated results.
9008 comma operator used -- The comma operator is thought by some to reduce readability in code.
9009 floating point variable used as loop counter -- The use of floating point variables as loop counters can produce surprising behavior if the accumulation of rounding errors results in a different numer of iterations than anticipated.
9011 more than one 'break' terminates loop -- More than one break statement was seen in a loop. Minimizing the number of exits from a loop is thought by some to reduce visual complexity of the code.
9012 sub-statement should be a compound statement -- Multiple authors have advised making sure the body of every iteration-statement and selection-statement be a compound-statement. However, no { was seen to begin the compound-statement.
9013 no 'else' at end of 'if ... else if' chain -- An if ... else if chain was seen without a final else statement. Providing such a statement helps to act as an analog to the default case of a switch-statement.
9014 default missing from switch statement -- A switch-statement was found without a default case. Providing such a case provides defensive programming.
9015 macro argument is used both with and without '#/##' and is subject to further replacement -- A macro argument was used both as an operand to the stringizing or pasting operators and not used as such. Moreover, this macro argument is subject to further replacement. This could cause confusion.
9016 pointer arithmetic other than array indexing used -- Array indexing is thought, by some, to be more readily understood and less error prone than other forms of pointer arithmetic.
9017 pointer arithmetic by increment or decrement used -- While at least one standards organization cautions against using any pointer arithmetic besides array indexing, the use of increment or decrement operators with pointers may represent an intuitive application and illustration of the underlying logic. Consequently, such constructs are separated from the prior message #9016 and placed under this one, allowing more fine tuning of Lint diagnostics.
9018 declaration of union type or object of union type, 'Type' -- Depending upon padding, alignment, and endianness of union, as well as the size and bit-order of their members, the use of unions can result in unspecified, undefined, or implementation defined behavior, prompting some to advise against their use.
9019 declaration of 'String' before #include -- The symbol mentioned in String was seen in a module with a subsequent #include directive. It can be argued that collecting all #include directives at the beginning of the module helps improve code readability and helps reduce the risk of undefined behavior resulting from any use of the ISO standard library before the relevant #include directive.
9020 header file name with non-standard character 'String' -- The use of non-standard characters in #include directives results in undefined behavior.
9021 use of '#undef' is discouraged: 'String' -- The use of the #undef directive can lead to confusion about whether or not a particular macro exists at a randomly given point of code.
9022 unparenthesized macro parameter in definition of macro 'String' -- Multiple authors have cautioned against the use of unparenthesized macro parameters in cases where the parameter is used as an expression. If care is not taken, unparenthesized macro parameters can result in operator precedence rules producing expressions other than intended.
9023 Multiple use of '#/##' operators in definition of macro 'String' -- Multiple use of such operators is thought by some to increase the risk of undefined behavior.
9024 '#/##' operator used in macro 'String' -- The use of such operators is thought to reduce code clarity and increase the risk of undefined behavior.
9025 More than two pointer indirection levels used for type 'Type' -- Three or more levels of pointer indirection may make it harder to understand the code.
9026 Function-like macro, 'String', defined -- Multiple authors have expressed reasons why a function, when possible, should be used in place of a function-like macro.
9027 Unpermitted operand to operator 'String' -- Out of concern for unspecified, undefined, and/or implementation defined behavior, some standards urge restrictions on certain types of operands when used with certain operators.
9028 Unpermitted arithmetic involving an essentially character type -- MISRA C 2012 has defined the concept of essentially character type and placed restrictions on the use of expressions with such a type.
9029 Mismatched essential type categories for binary operator -- MISRA C 2012 has defined the concept of essential type and placed restrictions on the use of expressions with certain types with respect to binary operators.
9030 Impermissible cast -- MISRA C 2012 has defined the concept of essential type and placed restrictions on the use of casts between certain types.
9031 Composite expression assigned to a wider essential type -- MISRA C 2012 has defined the concepts of composite expression and essential type and placed restrictions on assignments of the former.
9032 Composite expression with smaller essential type than other operand -- MISRA C 2012 has defined the concepts of composite expression and essential type and placed restrictions on operands to binary operators when at least one of the operands meets the definition of the former concept.
9033 Impermissible cast of composite expression -- MISRA C 2012 has defined the concepts of composite expression and essential type and placed restrictions on casts of the former. This message, when given, is also followed by text explaining why the cast is considered "impermissible".
9034 Expression assigned to a narrower or different essential type -- MISRA C 2012 has defined the concept of essential type and placed restrictions on assignments in relation to such types.
9035 Variable length array declared -- Some have expressed concern over the use of variable length arrays, noting how, even in common use cases of arrays, use of such arrays can result in undefined or unspecified behavior.
9036 Conditional expression should have essentially Boolean type -- MISRA C 2012 has defined the concept of essentially Boolean type and requires that the conditional expressions of all if and iteration-statements comply with this definition.
9037 Conditional of #if does not evaluate to 0 or 1 -- Some urge such a practice in the interest of strong typing.
9038 Flexible array member declared -- Flexible array members can alter the behavior of sizeof in surprising ways. Additionally, flexible array members often require dynamic memory allocation which may be problematic in safety critical code.
9039 Prohibited escape sequence usage -- An octal or hexadecimal escape sequence has been detected within a string or character literal which is not immediately followed by another escape sequence or end of literal. Such escape sequence usage has been deprecated on the grounds of potential confusion when attempting to read such code.
9041 goto 'Symbol' appears in block 'String' which is not nested in block 'String' which contains the label. -- It has been deemed safer by some experts that the block (i.e. compound statement) containing the goto should be the same as or nested within the block containing the label. Thus { label: { goto label; } } is permitted but { goto label; { label: } } is not. To assist the programmer, the message refers to the blocks using an identification code (Example: "1.2.1"). This identification scheme is defined as follows. (a) The outer block has an identification of 1. (b) If a particular block is identified by x then its immediate subblocks, if any, are identified as x.1, x.2, x.3, etc. Thus in the following 'code', { { } { { label: } { } } } label: lies in block 1.2.1.
9042 departure from MISRA switch syntax -- A switch-statement was found which does not comply with the MISRA switch-statement syntax.
9043 static keyword between brackets of array declaration -- Some advocate against using the keyword static in array declarations due to a perceived increased risk of undefined behavior.
9044 function parameter modified -- It has been advocated that function parameters be first copied to local variables where they can be modified rather than modifying the parameters directly.
9045 non-hidden definition of type 'Type' -- Some advise against including structure definitions unless the definition is required for the current module.
9046 Typographical ambiguity with respect to symbol, 'Symbol', Reasons, Location -- Some have warned against the use of identifiers which may be considered typographically ambiguous. In addition to the name of the previously seen symbol, the reasons Lint considers the identifiers to be ambiguous and the location of said previous symbol are provided in the message, if available.
9047 FILE pointer dereferenced -- At least one standards organization urges against this practice, directly or indirectly.
9048 unsigned integer literal without a 'U' suffix -- An integer literal of unsigned type was found without a 'U' suffix.
9049 increment/decrement operation combined with other operation with side-effects -- An expression was seen involving an increment or decrement operator and the expression also contained potential side-effects other than those resulting from said operator.
9050 dependence placed on C/C++ operator precedence -- Reliance on operator precedence was found in a particular expression. Using parentheses, it is felt, helps clarify the order of evaluation.
9051 macro 'Symbol' defined with the same name as a C keyword -- A macro was defined with the same name as an ISO C keyword. The use of such a macro causes undefined behavior.
9052 macro 'Symbol' defined with the same name as a C++ keyword -- A macro was defined with the same name as an ISO C++ keyword. The use of such a macro causes undefined behavior.
9053 the shift value is at least the precision of the essential type of the left hand side -- MISRA 2012 defines the notion of an "essential type". A quantity with a certain essential type, as defined by MISRA, was left shifted by a number exceeding the number of bits used to represent that essential type.
9054 designated initalizer used with array of unspecified dimension -- It has been advocated, when array initializers contain designators, the dimension of the array should be explicitly stated in the declaration. The initializer of the array in question has been found in violation of this recommendation.
9055 Most closely enclosing compound statement of a case/default is not the body of a switch -- Switch labels nested inside of compound statements within the corresponding switch are legal but can reduce comprehension and lead to unstructured code.
9056 Inline function 'Symbol' defined with storage-class specifier 'String' -- This message is issued for all inline functions defined with a storage-class specifier. +estring can be used to find all inline functions defined with a specific specifier. For example, +estring(9056, extern) will report all inline functions defined with extern.
9057 Lowercase L follows 'u' in literal suffix -- A lowercase letter "l" is used inside of a literal suffix following an upper or lowercase letter u. With some fonts, the lowercase letter "l" can be easily confused with the number one. This is less likely to happen when there is a "u" between the number and the "l" (as in 35ul), but some coding standards forbid the use of "l" in any literals. Message 620 reports the more suspicious case where the "l" immediately follows a number (as in 35l).
9058 tag 'Symbol' (Location) unused outside of typedefs -- A tag was used only in the course of creating a typedef. Was the tag unused by mistake (say a recursive reference inside the body of the struct was accidentally omitted)? Such tags are most often redundant and can be eliminated.
9059 C comment contains C++ comment -- A C++-style comment was seen inside a C-style comment. This can be confusing.
9060 trigraph in comment -- A trigraph was seen inside a comment. Since trigraphs are translated before preprocessing, a trigraph sequence like ??/ can have surprising results, especially in a C++ style comment where the trigraph sequence translates into a backslash.
9066 C++ comment contains C comment -- A C-style comment was seen inside a C++-style comment. This can result in confusion.
Top

PC-Lint / FlexeLint Meldungen nach MISRA C:2004 und MISRA C:1998


Die Meldungen 960 und 961 liefern die Details:

960 Violates MISRA Year Required Rule Name, String
-- MISRA is the"Guidelines for the use of the C Language in Vehicle Based Software". [9, 33] The first version of the MISRA Standard was released in 1998 and the second in 2004. Lint refers to the rules below in the form:
Rule I/D
where I is an integer rule number from the 1998 Standard and D is a decimal rule number from the 2004 Standard. When issuing messages, Lint will refer to the rules using the form:
Rule I - for the 1998 Standard and the form:
Rule D - for the 2004 Standard.

The list of required checks made for both MISRA 1998 and 2004 are:
(Rule 19/7.1) Octal constant used.
(Rule 32/9.3) Should initialize either all enum members or only the first.
(Rule 33/12.4) Side effects on right hand side of logical operator.
(Rule 42/12.10) Rule Comma operator used outside of 'for' expression.
(Rule 54/14.3) Null statement not in line by itself.
(Rule 57/14.5) continue statement should not be used.
(Rules 59/14.8 & 14.9) Left brace expected for if, else, for, do, and while.
(Rule 65/13.4) Floating point variable used as loop counter.
(Rule 68/8.6) Function not declared at file scope.
(Rule 69/16.1) Function has variable number of arguments.
(Rule 73/16.3) Either all parameters or no parameters should have identifiers.
(Rule 91/19.5 '#define/#undef' used within a block (Rule 91/19.5).
(Rule 98/19.12) Multiple use of '#' and/or '##' operators in macro definition.
(Rule 100/19.14) Non-standard use of 'defined' preprocessor operator.

Required checks made exclusively for MISRA 1998 are:
(Rule 58) break used outside of a switch.
(Rule 88) Header file name contains non-standard non-standard character.
(Rule 110) Bitfields inside union.


Required checks made exclusively for MISRA 2004 are:
(Rule 8.5) No definitions of objects or function in header files.
(Rules 10.1 & 10.2) Prohibited implicit conversion.
(Rules 10.3 & 10.4) Prohibited cast of complex expressions.
(Rule 10.5) Recasting required for operators '~' and '<<'.
(Rule 12.3) 'sizeof' used on expressions with side effect.
(Rule 12.7) Bitwise operator applied to signed underlying type.
(Rule 12.9) Prohibited operator applied to unsigned underlying type.
(Rule 14.6) More than one 'break' terminates loop.
(Rule 14.10) No 'else' at end of 'if ... else if' chain.
(Rule 15.4) Boolean value in switch expression.
(Rule 18.4) Unions shall not be used.
(Rule 19.6) Use of '#undef' prohibited.

MISRA 1998 checking is achieved using the -misra(1) option.
For MISRA 2004 checks, use -misra(2).
You may disable individual rules to your taste by using the Rule number in an esym option.
For example: -esym( 960, 75, 8? )
will suppress MISRA rules 75 and any of the those between 80 and 89 inclusive that are issued as the result of a 960. See [33, 34] for information on the MISRA guidelines


961 Violates MISRA Year Advisory RuleName, String

-- This message is issued for some violations of the MISRA advisory guidelines. Certain rules were advisories in the
1998 Standard and became required for the 2004 Standard and vice versa. Therefore, you might see some rules repeated here already listed above for message 960.

The list of advisory checks made for both MISRA 1998 and 2004 are:
(Rule 47/12.1) Dependence placed on C's operator precedence.
(Rule 87.19.1) Only preprocessor statements and comments before '#include'.
(Rule 93/19.7) Use of function-like macros is discouraged.
(Rule102)17.5) More than two pointer indirection levels used.

Advisory checks made exclusively for MISRA 1998 are:
(Rule 18) Constant requires numerical suffix.
(Rule 28) 'register' class discouraged.
(Rule 40) 'sizeof' used on expressions with side effect.(Rule 44 ) Redundant explicit casting.
(Rule 55) Non-case label.
(Rule 60) No 'else' at end of 'if ... else if' chain.
(Rule 63) Boolean value in switch expression.
(Rule 92) Use of '#undef' is discouraged.

Advisory checks made exclusively for MISRA 2004 are:
(Rule 19.2) Header file name contains non-standard non-standard character.
(Rule 19.13) No use of '#' or '##'.

Messages can be suppressed based on rule number. See also Message 960.

Top

PC-Lint / FlexeLint Meldungen nach MISRA C++:2008


Die Meldungen 1960 und 1963 liefern die Details:

 

1960 Violates MISRA Year Advisory RuleName, String
Violates MISRA C++ Required Rule Name, String -- In addition to
a C coding standard, MISRA has also compiled a C++ one. We
suggest use of the options file au-misra-cpp.lnt to activate
these and other MISRA C++ messages.

The list of checks made are as follows:

(Rule 0-1-8) Void return type for function without external side-effects.
(Rule 2-13-2) Octal constant or escape sequence used.
(Rule 2-13-4) Lower case literal suffix.
(Rule 3-1-1) Object/function definitions in headers.
(Rule 3-1-2) Function not declared at file scope.
(Rule 5-0-3) Implicit conversion of cvalue.
(Rule 5-0-4) Implicit conversion changes signedness.
(Rule 5-0-5) Implicit conversion between integer and floating point types.
(Rule 5-0-6) Implicit conversion to smaller type.
(Rule 5-0-7) Cast of cvalue between integer and floating point types.
(Rule 5-0-8) Cast of cvalue to larger type.
(Rule 5-0-9) Cast of cvalue changes signedness.
(Rule 5-0-10) Recasting required for operators '~' and '&lt;&lt;'.
(rule 5-0-19) More than two pointer indirection levels used.
(Rule 5-0-21) Bitwise operator applied to signed underlying type .
(Rule 5-2-12) Array-pointer decay when passing the array to a function .
(Rule 5-3-2) Prohibited operator applied to unsigned underlying type: .
(Rule 5-3-3) Overloading unary &amp;.
(Rule 5-3-4) 'sizeof' used on expressions with side effect.
(Rule 5-14-1) Side effects on right hand side of logical operator.
(Rule 5-18-1) Comma operator used.
(Rule 6-2-3) Null statement not in line by itself.
(Rules 6-3-1 and 6-4-1) Left brace expected for if, else, for, do, switch and while.
(Rule 6-4-2) No 'else' at end of 'if ... else if' chain.
(Rule 6-4-7) Boolean value in switch expression.
(Rule 6-6-2) Gotos jumping to an earlier point in the code.
(Rule 6-6-3) continue statement should not be used.
(Rule 6-6-4) More than one 'break' terminates loop.
(Rule 7-3-1) Global declarations other than main(), namespace declarations,
extern "C" declarations and arithmetic typedefs.
(Rule 7-3-2) Using the identifier main for functions other than the global one.
(Rule 7-3-3) Unnamed namespaces in headers.
(Rule 7-3-4) No using-directives allowed.
(Rule 7-3-6) using-directives or using declarations
(except class and/or block scope using declarations) in header files.
(Rule 8-0-1) Multiple declarators in a declaration.
(Rule 8-4-1) Function has variable number of arguments.
(Rule 8-5-3) Should initialize either all enum members or only the first.
(Rule 9-5-1) Unions shall not be used.
(Rule 14-8-1) Explicit specialization of overloaded function templates.
(Rule 15-1-3) Empty throw outside of a catch block.
(Rule 15-3-7) Catch handler after catch(...) in a try-catch sequence.
(Rule 16-0-1) Only preprocessor statements and comments before '#include'.
(Rule 16-0-2) '#define/#undef' used within a block.
(Rule 16-0-3) Use of '#undef' is discouraged.
(Rule 16-0-4) Use of function-like macros is discouraged.
(Rule 16-1-1) Non-standard use of 'defined' preprocessor operator.
(Rule 16-2-4) Header file name with non-standard character: .
(Rule 16-3-1) Multiple use of '#' and/or '##' operators in macro definition.

You may disable individual rules to your taste by using the Rule
number in an esym option; see Message 960.


1963 Violates MISRA Year Advisory RuleName, String
Violates MISRA C++ Advisory Rule Name, String -- This message is
issued for some violations of the MISRA C++ advisory guidelines.
We suggest use of the options file au-misra-cpp.lnt to activate
these and other MISRA C++ messages.

The list of checks made are as follows:
(Rule 2-5-1) Possible digraph used.
(Rule 5-0-2) Dependence placed on C's operator precedence.
(Rule 14-8-2) Mixing template and non-template functions in a viable sets.
(Rule 15-0-2) Throwing a pointer expression.
(Rule 16-2-5) Header file name with non-standard character.
(Rule 16-3-2) No use of '#' or '##'.

Messages can be suppressed based on rule number. See Message 960.

Top