PC-lint Plus HTML Reference Manual: Messages

22 Messages

Every diagnostic message has an associated message number. By looking up the number in the list below you can obtain additional information about the cause of the diagnostic. This information can also be extracted from PC-lint Plus as a plain text or JSON ﬁle using the -dump_messages option.

Messages pertaining speciﬁcally to C++ generally reside in the 1xxx and 3xxx ranges while those applicable to C or both C and C++ reside in the xxx and 2xxx ranges. After a possible 1000 is subtracted oﬀ, the remainder lies in the range 0-999.

Remainders in the range 1-399 are errors that may be the result of incorrect syntax, a violation of the semantics of the language or a processing error. Some serious errors can be fatal, unsuppressible, or both. Errors are generally mistakes in the program or the PC-lint Plus conﬁguration and should be corrected. While most errors can be suppressed, it is not advisable to do so unless the root cause is understood and it is determined that suppression is both safe and the only available course of action. Suppressing error messages can hide conﬁguration issues that may result in incorrect or incomplete analysis.

Remainders in the 400-699 range are warning messages that indicate that something is potentially wrong with the program being examined. Remainders in the range 700-899 designate informational messages; these messages serve to point out unusual constructs, generally acknowledged bad practices, and potential pitfalls.

Remainders in the range 900-999 are called "Elective Notes" and diagnose speciﬁc points of interest that do not necessarily represent any deﬁciency in the code but may be of interest to certain users. They are not automatically presented. You may examine the list to see if you wish to be alerted to any of them.

Aside from the 4 ranges mentioned above, the 4xxx, 5xxx, and 6xxx ranges are used for C and C++ error messages, the 8xxx range is reserved for user-deﬁned messages, and the 9xxx ranges is used for C and C++ elective notes. Messages in the 7xxx range are reserved for future use.

Note that there are over 2000 clang compiler errors that PC-lint Plus reports in the range 4001-6999. Because these messages are generally self-explanatory error messages, they are not included in this document.

CERT C guideline titles are excerpted from SEI CERT C Coding Standard © Carnegie Mellon University 1995–2016. See chapter 25 for full details.

MISRA headline text, appearing in support statements that follow relevant message descriptions, is used with permission and subject to copyright as detailed below.

Headline text from "MISRA-C:2004 Guidelines for the use of the C language in critical systems" is Copyright The MISRA Consortium Limited © 2004.
Headline text from "MISRA C++:2008 Guidelines for the use of the C++ language in critical systems" is Copyright The MISRA Consortium Limited © 2008.
Headline text from "MISRA C:2012 Guidelines for the use of the C language in critical systems" is Copyright The MISRA Consortium Limited © 2013.
Headline text from "MISRA C:2023 Guidelines for the use of the C language in critical systems" is Copyright The MISRA Consortium Limited © 2023.
Headline text from "MISRA C++:2023 Guidelines for the use of the C++ language in critical systems" is Copyright The MISRA Consortium Limited © 2023.
Headline text from "MISRA C:2025 Guidelines for the use of the C language in critical systems" is Copyright The MISRA Consortium Limited © 2025.

Range	Description	Warning Level

1-199	C Syntax Errors	1
200-299	Internal Errors	1
300-399	Fatal Errors	1
400-699	C Warnings	2
700-899	C Informational	3
900-999	C Elective Notes	4
1000-1199	C++ Syntax Errors	1
1200-1299	Internal Errors	1
1300-1399	C++ Fatal Errors	1
1400-1699	C++ Warnings	2
1700-1899	C++ Informational	3
1900-1999	C++ Elective Notes	4
2000-2199	C Syntax Errors	1
2200-2399	Reserved
2400-2699	C Warnings	2
2700-2899	C Informational	3
2900-2999	C Elective Notes	4
3000-3199	C++ Syntax Errors	1
3200-3399	Reserved
3400-3699	C++ Warnings	2
3700-3899	C++ Informational	3
3900-3999	C++ Elective Notes	4
4000-6999	C and C++ Errors	1
7000-7999	Reserved
8000-8999	User Deﬁned	3
9000-9999	Misc Elective Notes	4

Glossary

A few of the terms used in the commentary below are:

argument	The actual argument of a function as opposed to a dummy (or formal) parameter of a function (see parameter below).
arithmetic	Any of the integral types (see below) plus float, double, and long double.
Boolean	In general, the word Boolean refers to quantities that can be either true or false. An expression is said to be Boolean (perhaps it would be better to say ‘deﬁnitely Boolean’) if it is of the form: operand op operand where op is a relational (> >= < <=), an equality operator (== !=), logical And (&&) or logical Or (\|\|). A context is said to require a Boolean if it is used in an if or while clause or if it is the 2nd expression of a for clause or if it is an argument to one of the operators: && or \|\|. An expression needn’t be deﬁnitely Boolean to be acceptable in a context that requires a Boolean. Any integer or pointer is acceptable.
declaration	Gives properties about an object or function (as opposed to a deﬁnition).
deﬁnition	that which allocates space for an object or function (as opposed to a declaration) and that may also indicate properties about the object. There should be only one deﬁnition for an object but there may be many declarations.
integral	a type that has properties similar to integers. These include char, short, int, and long and the unsigned variations of any of these.
scalar	any of the arithmetic types plus pointers.
lvalue	is an expression that can be used on the Left hand side of an assignment operator (=). Some contexts require lvalues such as autoincrement (++) and autodecrement (–).
macro	an abbreviation deﬁned by a #define statement. It may or may not have arguments.
member	elements of a struct and of a union are called members.
module	that which is compiled by a compiler in a single independent compilation. It typically includes all the text of a .c (or a .cpp or .cxx, etc.) ﬁle plus any text within any #include ﬁle(s).
parameter	A formal parameter of a function as opposed to an actual argument (see argument above).

22.1 Message Parameters

Most messages are parameterized with one or more pieces of information that may be diﬀerent each time the message is issued such as the name of a symbol being referenced, the types involved in a conversion, or a string representing dynamic text. These parameters can be employed for suppression purposes using -esym , -estring , and -etype .

There are three categories of message parameters: Strings, Symbols, and Types. Symbol parameters in a message are represented as symbol in the message descriptions below and may be used with the -esym option to suppress the message. Type parameters are represented as type and may be used with -etype to suppress the message. -etype may also be used to suppress symbol parameters by using the type of a symbol appearing in the message (see +typename for information about obtaining a type string suitable for use with -etype in this fashion). String parameters consist of virtually every other italicized parameter including:

context
detail
ﬁle
integer
name
operator
string
strong-type

Additionally, some messages contain dynamic text, which is represented by a slash in the message such as:

444: for statement condition tests incremented/decremented pointer for null

-estring can be used to suppress such messages when one of these values is used in the message, e.g. -estring(444, incremented). -esym can also be used to suppress on String parameters when the fsn ﬂag is ON (which it is by default).

Detailed parameter information for speciﬁc instances of messages can be obtained by using +paraminfo .

22.2 Messages 1-999

1
error
unclosed comment
End of ﬁle was reached with an open comment still unclosed.
Supports CERT C MSC04-C - Use comments consistently and in a readable fashion
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2
error
unclosed quote
An end of line was reached and a matching quote character (single or double) to an earlier quote character on the same line was not found.
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

3
error
string without #if
A #elif was encountered not in the scope of a #if, #ifdef or #ifndef.

5
error
too many #endif directives
A #endif was encountered not in the scope of a #if or #ifdef or #ifndef.

6
error
#include nested too deeply
The maximum internal #include nesting depth was reached, likely as the result of a #include cycle. This is a fatal error.

8
error
unclosed #if
A #if (or #ifdef or #ifndef) was encountered without a corresponding #endif.
Supports AUTOSAR17 Rule M16-1-2
Supports AUTOSAR19 Rule M16-1-2
Supports MISRA C 2004 Rule 19.17 - All #else, #elif and #endif preprocessor directives shall reside in the same ﬁle as the #if or #ifdef directive to which they are related.
Supports MISRA C 2012 Rule 20.14 - All #else, #elif and #endif preprocessor directives shall reside in the same ﬁle as the #if, #ifdef or #ifndef directive to which they are related
Supports MISRA C:2023 Rule 20.14 - All #else, #elif and #endif preprocessor directives shall reside in the same ﬁle as the #if, #ifdef or #ifndef directive to which they are related
Supports MISRA C:2025 Rule 20.14
Supports MISRA C++:2008 Rule 16-1-2 - All #else, #elif and #endif preprocessor directives shall reside in the same ﬁle as the #if or #ifdef directive to which they are related.
Supports MISRA C++:2023 Rule 19.1.2 - All #else, #elif and #endif preprocessor directives shall reside in the same ﬁle as the #if, #ifdef or #ifndef directive to which they are related

9
error
string after #else
A given #if contained a #else, which in turn was followed by either another #else or a #elif. The error message gives the line of the #if statement that started the conditional that contained the aberration.

10
error
expecting detail
The expected token (provided in detail) could not be found. For example:

void foo(int, int); 
void bar() { 
   foo(1, 2; 
}

will yield the error:

error 10: expecting ')' 
   foo(1, 2; 
          ^ 
supplemental 891: to match this '(' 
   foo(1, 2; 
      ^

due to the missing closing parenthesis at the end of the function call.

12
error
need < or "
After a #include is detected and after macro substitution is performed, a ﬁle speciﬁcation of the form <ﬁlename> or "ﬁlename" is expected.
Supports MISRA C 2004 Rule 19.3 - The #include directive shall be followed by either a <ﬁlename> or "ﬁlename" sequence.
Supports MISRA C 2012 Rule 20.3 - The #include directive shall be followed by either a <ﬁlename> or "ﬁlename" sequence
Supports MISRA C:2023 Rule 20.3 - The #include directive shall be followed by either a <ﬁlename> or "ﬁlename" sequence
Supports MISRA C:2025 Rule 20.3
Supports MISRA C++:2008 Rule 16-2-6 - The #include directive shall be followed by either a <ﬁlename> or "ﬁlename" sequence.
Supports MISRA C++:2023 Rule 19.2.2 - The #include directive shall be followed by either a <ﬁlename> or "ﬁlename" sequence

13
error
'string' cannot be signed or unsigned
A type adjective such as long, unsigned, etc. cannot be applied to the type, which follows.

15
error
symbol symbol redeclared (type vs. type)
The named symbol has been previously declared or deﬁned in some other module (location given) with a type diﬀerent from the type given by the declaration at the current location. The parenthesized type parameters provide the two diﬀering types.
Supports AUTOSAR17 Rule M3-2-2
Supports AUTOSAR19 Rule M3-2-2
Supports MISRA C 2004 Rule 8.4 - If objects or functions are declared more than once their types shall be compatible.
Supports MISRA C 2012 Rule 8.4 - A compatible declaration shall be visible when an object or function with external linkage is deﬁned
Supports MISRA C:2023 Rule 8.4 - A compatible declaration shall be visible when an object or function with external linkage is deﬁned
Supports MISRA C:2025 Rule 8.4
Supports MISRA C++:2008 Rule 3-2-2 - The One Deﬁnition Rule shall not be violated.

16
error
unknown preprocessor directive
A # directive is not followed by a recognizable word. If this is not an error, use the +ppw option. (Section 4.12 Compiler Adaptation ).
Supports AUTOSAR17 Rule M16-0-8
Supports AUTOSAR19 Rule M16-0-8
Supports MISRA C 2004 Rule 19.16 - Preprocessing directives shall be syntactically meaningful even when excluded by the preprocessor.
Supports MISRA C 2012 Rule 20.13 - A line whose ﬁrst token is # shall be a valid preprocessing directive
Supports MISRA C:2023 Rule 20.13 - A line whose ﬁrst token is # shall be a valid preprocessing directive
Supports MISRA C:2025 Rule 20.13
Supports MISRA C++:2008 Rule 16-0-8 - If the # token appears as the ﬁrst token on a line, then it shall be immediately followed by a preprocessing token.
Supports MISRA C++:2023 Rule 19.0.1 - A line whose ﬁrst token is # shall be a valid preprocessing directive

18
error
symbol symbol redeclared (typediﬀ)
A symbol is being redeclared. The parameter typediﬀ provides further information on how the types diﬀer.
Supports AUTOSAR17 Rule M2-10-6
Supports AUTOSAR17 Rule M3-2-1
Supports AUTOSAR19 Rule M3-2-1
Supports CERT C DCL40-C - Do not create incompatible declarations of the same function or object
Supports MISRA C 2004 Rule 8.4 - If objects or functions are declared more than once their types shall be compatible.
Supports MISRA C 2012 Rule 8.2 - Function types shall be in prototype form with named parameters
Supports MISRA C 2012 Rule 8.3 - All declarations of an object or function shall use the same names and type qualiﬁers
Supports MISRA C:2023 Rule 8.2 - Function types shall be in prototype form with named parameters
Supports MISRA C:2023 Rule 8.3 - All declarations of an object or function shall use the same names and type qualiﬁers
Supports MISRA C:2025 Rule 8.2
Supports MISRA C:2025 Rule 8.3
Supports MISRA C++:2008 Rule 2-10-6 - If an identiﬁer refers to a type, it shall not also refer to an object or a function in the same scope.
Supports MISRA C++:2008 Rule 3-2-1 - All declarations of an object or function shall have compatible types.

19
error
declaration requires a type speciﬁer
A name appeared by itself without an associated type in what appears to be a declaration, e.g.:

x;

In C, this is a declaration of x with an implicit int type and warning 601 would be issued. In C++ this is illegal as the type must be explicit.

21
error
array initializer must be an initializer list
An initializer for an indeﬁnite size array must begin with a left brace.

24
error
expected an expression
An operator was found at the start of an expression but it was not a unary operator.

25
error
character constant too long for its type
Too many characters were encountered in a character constant (a constant bounded by ’ marks).

29
error
duplicated type-speciﬁer, 'detail'
This message is issued in C90 mode when a type speciﬁer is duplicated within a declaration. For example:

const const int i = 0;

will result in message 29 when in C90 mode, which forbids duplicate speciﬁers. In C99 and later, duplicate speciﬁers are ignored and such a construct will instead be greeted with warning 2435 .

31
error
redeﬁnition of symbol symbol
A data object or function previously deﬁned in this module is being redeﬁned.
Supports AUTOSAR17 Rule M3-2-1
Supports AUTOSAR17 Rule M3-2-2
Supports AUTOSAR19 Rule M3-2-1
Supports AUTOSAR19 Rule M3-2-2
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3
Supports MISRA C++:2008 Rule 3-2-1 - All declarations of an object or function shall have compatible types.
Supports MISRA C++:2008 Rule 3-2-2 - The One Deﬁnition Rule shall not be violated.

32
error
ﬁeld size (member symbol) should not be zero
The length of a ﬁeld was given as non-positive, (0 or negative).

33
error
illegal constant 'integer' in octal constant
A constant was badly formed as when an octal constant contains one of the digits 8 or 9.

34
error
non-compile-time-constant initializer
A non-constant initializer was found for a static data item.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

35
error
initializer has side-eﬀects
An initializer with side eﬀects was found for a static data item.

40
error
undeclared identiﬁer detail
Within an expression, an identiﬁer was encountered that had not previously been declared and was not followed by a left parenthesis.
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

44
error
need a switch for case-label
A case or default statement occurred outside a switch.
Supports MISRA C 2004 Rule 15.1 - A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement.
Supports MISRA C 2012 Rule 16.2 - A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement
Supports MISRA C:2023 Rule 16.2 - A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement
Supports MISRA C:2025 Rule 16.2

47
error
invalid argument type type to unary expression
Unary minus requires an arithmetic operand.

48
error
indirection requires pointer operand (type invalid)
Unary * or the left hand side of the ptr (->) operator requires a pointer operand.
Supports MISRA C 2012 Rule 10.1 - Operands shall not be of an inappropriate essential type
Supports MISRA C:2023 Rule 10.1 - Operands shall not be of an inappropriate essential type
Supports MISRA C:2025 Rule 10.1

50
error
attempted to take the address of a non-lvalue of type type
Unary & operator requires an lvalue (a value suitable for placement on the left hand side of an assignment operator).

51
error
expected integral type for bitwise complement operator
Unary ~ expects an integral type (signed or unsigned char, short, int, or long).

52
error
expected an lvalue
Assignment, increment, and decrement operators require a modiﬁable lvalue. Remember that casts do not normally produce lvalues. Thus

++(char *)p;

is illegal according to the ANSI/ISO standard.

53
error
expected a scalar and not expression of type type
Autodecrement (--) and autoincrement (++) operators may be applied only to scalars (arithmetics and pointers) or to objects for which these operators have been deﬁned.

54
error
division/remainder by 0
The constant 0 was used on the right hand side of the division operator (/) or the remainder operator (%).
Supports CWE-369 - Divide By Zero
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

56
error
pointer addition requires an integral type
Add/subtract operator requires scalar types and pointers may not be added to pointers.

57
error
operands to bitwise operator must be integral
Bit operators ( &, | and ^ ) require integral arguments.

59
error
number of bits to shift by must be an integer
The amount by which an item can be shifted must be integral.

60
error
value to be shifted must be an integer
The value to be shifted must be integral.

66
error
'void' must be the ﬁrst and only parameter if speciﬁed
A void type was employed where it is not permitted. If a void type is placed in a prototype then it must be the only type within a prototype.

72
error
bad option 'option': detail
An unrecognized or invalid option was encountered on the command line, in the LINT environment variable, in an indirect ﬁle, or in a lint comment. The option parameter contains the oﬀending option and detail provides additional information about the issue.

76
error
cannot open ﬁle 'ﬁle': detail
ﬁle is the name of the ﬁle. The named ﬁle could not be opened for output. detail contains information about the failure. This error is issued when PC-lint Plus is directed to write to a ﬁle with the options -oe/+oe, -os/+os, -write_file, or +stack but it unable to open the speciﬁed ﬁle for writing.

82
error
string detail must not return void expression
The expression form of a return statement was used in a function that was declared as returning void, e.g.:

void foo() { 
   return 1;  // Error 82 
}

Note that the ANSI/ISO C standard does not allow the expression form of a return statement in a function that returns void, even when the provided expression has void type. For example:

void foo_v(); 
int foo_i(); 
 
void bar(int x) { 
   if (x) return foo_v();        // Error 82 
   else return (void) foo_i();    // Error 82 
}

If your compiler supports the latter case, you may safely suppress this message in such situations.

83
error
incompatible pointer types (type and type) with subtraction
Two pointers being subtracted have indirect types that diﬀer.

85
error
array symbol has dimension 0
An array (named symbol) was declared without a dimension in a context that required a non-zero dimension.

86
error
structure symbol has zero elements
A structure was declared (in a C module) that had no data members. Though legal in C++ this is not legal C.
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

92
error
negative length of integer for bit ﬁeld string
A negative array dimension or bit ﬁeld length is not permitted.

95
error
expected a macro parameter
The # operator was found within a macro deﬁnition but was not immediately followed by a parameter of the macro as is required by the standards.

104
error
cannot combine with previous 'parameter' declaration speciﬁer
Two consecutive conﬂicting types were found such as int followed by double. Remove one of the types.

106
error
illegal constant
A string constant was found within a preprocessor expression as in

#if ABC == "abc"

Such expressions should be integral expressions.

107
error
label name not deﬁned
The name appeared in a goto but there was no corresponding label.
Supports AUTOSAR17 Rule M6-6-2
Supports AUTOSAR19 Rule M6-6-2
Supports MISRA C++:2008 Rule 6-6-2 - The goto statement shall jump to a label declared later in the same function body.

108
error
invalid context for 'break' statement
A continue or break statement was encountered without an appropriate surrounding context such as a for, while, or do loop or, for the break statement only, a surrounding switch statement.

115
error
struct/union not deﬁned
A reference to a structure or a union was made that required a deﬁnition and there is no deﬁnition in scope. For example, a reference to p->a where p is a pointer to a struct that had not yet been deﬁned in the current module.
Supports MISRA C 2004 Rule 18.1 - All structure or union types shall be complete at the end of a translation unit.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

116
error
inappropriate storage class
A storage class other than register was given in a section of code that is dedicated to declaring parameters. The section is that part of a function preceding the ﬁrst left brace.

117
error
inappropriate storage class
A storage class (indicated as either auto or register) was provided outside any function. Such storage classes are appropriate only within functions.

118
error
too few arguments (integer vs integer) for prototype
The number of arguments provided for a function was less than the number indicated by a prototype in scope.
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports MISRA C 2004 Rule 16.6 - The number of arguments passed to a function shall match the number of parameters.

119
error
too many arguments (integer vs integer) for prototype
The number of arguments provided for a function was greater than the number indicated by a prototype in scope.
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports MISRA C 2004 Rule 16.6 - The number of arguments passed to a function shall match the number of parameters.

124
error
pointer to void not allowed
A pointer to void was used in a context that does not permit void. This includes subtraction, addition and the relationals (> >= < <=).

128
error
pointer to function not allowed
A pointer to a function was found in an arithmetic context such as subtraction, addition, or one of the relationals (> >= < <=).

130
error
type is not an integral type
The expression in a switch statement must be some variation of an int (possibly long or unsigned) or an enum.

131
error
too few arguments provided to function-like macro invocation
This message is issued when a macro with arguments (function-like macro) is invoked and an incorrect number of arguments is provided.
Supports MISRA C 2004 Rule 19.8 - A function-like macro shall not be invoked without all of its arguments.

132
error
expected function deﬁnition
A function declaration with identiﬁers between parentheses is the start of an old-style function deﬁnition (K&R style). This is normally followed by optional declarations and a left brace to signal the start of the function body. Either replace the identiﬁer(s) with type(s) or complete the function with a function body.

136
error
illegal macro name
The ANSI/ISO standard restricts the use of certain names as macros. defined is on the restricted list.
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 21.1 - #deﬁne and #undef shall not be used on a reserved identiﬁer or reserved macro name
Supports MISRA C:2023 Rule 21.1 - #deﬁne and #undef shall not be used on a reserved identiﬁer or reserved macro name
Supports MISRA C:2025 Rule 20.15

138
error
cannot create recursive strong type relationship between 'strong-type' and 'strong-type'
An attempt was made to add a strong type parent to a typedef type. The attempt is either explicit (with the -strong option) or implicit with the use of a typedef to a known strong type. This attempt would have caused a loop in the strong parent relationship. Such loops are simply not tolerated.

139
error
cannot take sizeof a function
There is an attempt to take the sizeof a function.

148
error
member name previously declared
The indicated member was previously declared within the same structure or union. Although a redeclaration of a function may appear benign it is just not permitted by the rules of the language. One of the declarations should be removed.

157
error
no data may follow an incomplete array
An incomplete array is allowed within a struct of a C99 or C++ program but no data is allowed to appear after this array. For example

struct A { int x; int a[]; int b; };

This diagnostic is issued when the ’b’ is seen.

160
error
the sequence ({ is non standard and is taken to introduce a GNU statement expression
PC-lint Plus encountered the sequence ’({’ in a context where an expression (possibly a sub-expression) is expected. For example:

int n = ({  //Error 160 here 
     int y = foo (); 
     int z; 
     if (y > 0) 
        z = y; 
     else z = - y; 
     z; }) 
     // Now n has the last value of z.

In addition to being a non-standard GNU extension, there are some caveats described in the GCC documentation (especially when used in C++) that can lead to subtle bugs. Programmers who intend to work only with C code with the GNU extensions may safely disable this diagnostic.

161
error
repeated use of parameter symbol in parameter list
The name of a function parameter was repeated. For example:

void f( int n, int m, int n ) {}

will cause this message to be issued. Names of parameters for a given function must all be diﬀerent.

163
error
goto statement jumps into protected context
A goto statement jumps to a label which is inside a protected context. An example of a protected context may be inside a try-block’s statement, or a handler’s statement.

void fn(void) { 
   goto Inside_Try;  // error 164 
   try { 
Inside_Try: 
      ; 
   } catch (...) {} 
}

See message 165 for a switch statement case label inside of a protected context.
Supports AUTOSAR17 Rule M15-0-3
Supports AUTOSAR19 Rule M15-0-3
Supports MISRA C++:2008 Rule 15-0-3 - Control shall not be transferred into a try or catch block using a goto or a switch statement.

164
error
switch statment case label would jump into protected context
A switch statement case label is inside a protected context. An example of a protected context may be inside a try-block’s statement, or a handler’s statement.

void fn(int i) { 
   switch (i) { 
      try { 
   case 1:  // error 165 
          ; 
      } catch (...) {} 
   }; 
}

See message 164 for a goto that jumps into a protected context.
Supports AUTOSAR17 Rule M15-0-3
Supports AUTOSAR19 Rule M15-0-3
Supports MISRA C++:2008 Rule 15-0-3 - Control shall not be transferred into a try or catch block using a goto or a switch statement.

175
error
cannot pass string to variadic string; expected type from format string was type
An initializer list or an expression of a type that cannot be passed as a variadic function argument was given as the argument to a printf/scanf style function. The string parameter speciﬁes the type of the argument passed, the type parameter speciﬁes the type that was expected from the format string.
Supports CERT C DCL11-C - Understand the type issues associated with variadic functions

176
error
operand of type type cannot be cast to function pointer type type
An attempt was made to perform an illegal cast from a type (such as a ﬂoat) to a function pointer for which such conversion is undeﬁned.
Supports MISRA C 2004 Rule 11.1 - Conversions shall not be performed between a pointer to a function and any type other than an integral type.
Supports MISRA C 2012 Rule 11.1 - Conversions shall not be performed between a pointer to a function and any other type
Supports MISRA C:2023 Rule 11.1 - Conversions shall not be performed between a pointer to a function and any other type
Supports MISRA C:2025 Rule 11.1

177
error
operand of type type cannot be cast to object pointer type type
An attempt was made to perform an illegal cast from a type (such as a ﬂoat) to an object pointer for which such conversion is undeﬁned.
Supports MISRA C 2004 Rule 11.2 - Conversions shall not be performed between a pointer to object and any type other than an integral type, another pointer to object type or a pointer to void.
Supports MISRA C 2012 Rule 11.6 - A cast shall not be performed between pointer to void and an arithmetic type
Supports MISRA C 2012 Rule 11.7 - A cast shall not be performed between pointer to object and a non-integer arithmetic type
Supports MISRA C:2023 Rule 11.6 - A cast shall not be performed between pointer to void and an arithmetic type
Supports MISRA C:2023 Rule 11.7 - A cast shall not be performed between pointer to object and a non-integer arithmetic type
Supports MISRA C:2025 Rule 11.4
Supports MISRA C:2025 Rule 11.6

178
error
function pointer of type type cannot be cast to type type
An attempt was made to perform an illegal cast from a function pointer to a type (such as a ﬂoat) for which such conversion is undeﬁned.
Supports MISRA C 2004 Rule 11.1 - Conversions shall not be performed between a pointer to a function and any type other than an integral type.
Supports MISRA C 2012 Rule 11.1 - Conversions shall not be performed between a pointer to a function and any other type
Supports MISRA C:2023 Rule 11.1 - Conversions shall not be performed between a pointer to a function and any other type
Supports MISRA C:2025 Rule 11.1

179
error
object pointer of type type cannot be cast to type type
An attempt was made to perform an illegal cast from an object pointer to a type (such as a ﬂoat) for which such conversion is undeﬁned.
Supports MISRA C 2004 Rule 11.2 - Conversions shall not be performed between a pointer to object and any type other than an integral type, another pointer to object type or a pointer to void.
Supports MISRA C 2012 Rule 11.6 - A cast shall not be performed between pointer to void and an arithmetic type
Supports MISRA C 2012 Rule 11.7 - A cast shall not be performed between pointer to object and a non-integer arithmetic type
Supports MISRA C:2023 Rule 11.6 - A cast shall not be performed between pointer to void and an arithmetic type
Supports MISRA C:2023 Rule 11.7 - A cast shall not be performed between pointer to object and a non-integer arithmetic type
Supports MISRA C:2025 Rule 11.4
Supports MISRA C:2025 Rule 11.6

180
error
cannot generate mangled name for symbol symbol whose type depends on string
Name mangling refers to the process of taking the declared name of a symbol and producing a new name which additionally incorporates information about the symbol, for example its type, return types, parameter types, enclosing classes or namespaces, etc. Typical compilers and linkers use mangled names to implement function overloading and to uniformly refer to and disambiguate external entities.

When certain combinations of compiler extensions are mixed in a manner that does not conform to the language standard, situations may arise where it is not possible to systematically construct a mangled name to allow an entity to be cross-referenced between translation units. This message is parameterized by the category of grammatical entity for which mangling failed.

181
error
invalid direct member access of atomic structure or union of type type
A struct or union qualiﬁed with _Atomic was directly accessed via the . or -> operator. For example:

typedef struct a { 
   unsigned char i; 
   unsigned char j; 
} a_t; 
 
_Atomic a_t myAtomStruct; 
 
void foo() { 
   myAtomStruct.i = 7U;       // error 181 
   _Atomic a_t *atom_struct_ptr = &myAtomStruct; 
   atom_struct_ptr->j = 42U;  // error 181 
}

will produce this message. Operations on atomic variables are guaranteed to avoid data races, but only when done so through the dedicated access functions. Directly accessing members of an atomic structure or union results in undeﬁned behavior.

Supports MISRA C 2012 AMD4 Rule 12.6 - Structure and union members of atomic objects shall not be directly accessed
Supports MISRA C:2023 Rule 12.6 - Structure and union members of atomic objects shall not be directly accessed
Supports MISRA C:2025 Rule 12.6

305
error
unable to open module 'ﬁle'
The module speciﬁed in the ﬁle parameter could not be opened for reading, perhaps because it does not exist where PC-lint Plus expected to ﬁnd it. If the module is not in the directory from which PC-lint Plus was invoked, it will be searched for in the directories speciﬁed by any -i options. If the ﬁle exists in a directory not being searched, a -i option can be used to cause PC-lint Plus to search the appropriate directory.

307
error
cannot open indirect ﬁle 'ﬁle'
The indirect ﬁle speciﬁed in the ﬁle parameter could not be opened for reading, perhaps because it does not exist where PC-lint Plus expected to ﬁnd it. If the ﬁle is not in the directory from which PC-lint Plus was invoked, it will be searched for in the directories speciﬁed by any -i options. If the ﬁle exists in a directory not being searched, a -i option can be used to cause PC-lint Plus to search the appropriate directory.

308
error
can't write to ﬁle 'ﬁle' for PCH construction
stdout was found to equal NULL. This is most unusual.

309
error
#error detail
The #error directive was encountered. This error is fatal by default, but can be bypassed using the fce ﬂag.

311
error
indirect ﬁle depth limit of 'integer' exceeded
The indirect (.lnt) ﬁle nesting depth has reached an internal limit (the current limit is 100). The most likely cause of this error is unintended recursion between indirect ﬁles.

314
error
cannot use indirect ﬁle 'ﬁle' again
The indirect ﬁle named was previously encountered. If this was not an accident, you may suppress this message.

315
error
message limit exceeded
The maximum number of messages speciﬁed using the -limit option was exceeded.

318
error
EOF for a module found within a macro argument list
The end of a module was encountered while processing the argument list of a macro invocation.

319
error
size option misconﬁguration: 'type' has size integer and 'type' has size integer
A fatal inconsistency in the sizes of the fundamental data types was introduced by use of the size options. The -s option allows for conﬁguration of the sizes of the fundamental data types. If these options are used to specify sizes that violate the basic tenets of the language, this message will be issued. Such an example would include specifying a byte size for short int that is larger than int.

322
error
unable to open include ﬁle 'ﬁle'
ﬁle is the name of the include ﬁle, which could not be opened. Directory search is controlled by options: -i , +fdi , +fsi and the INCLUDE environment variable (See Section 18.2.1 INCLUDE Environment Variable ). This is a suppressible fatal message. If option -e322 is used processing will continue.

330
error
static_assert failedstring
This message is issued when the constant-expression of a static-assert-declaration (either C11’s _Static_assert or C++11’s static_assert) evaluates to false. If PC-lint Plus issues this error message but the compiler does not, see whether the Lint conﬁguration matches the compiler conﬁguration: consider potential diﬀerences in pre-deﬁned macros and include search options, and ensure that size options match the target machine. Diﬀerences in these conﬁguration details could lead to diﬀerences in evaluation of the constant-expression.

331
error
ﬁle 'parameter' has been modiﬁed since the string 'parameter' was built: string changedstring
Use of the speciﬁed precompiled header was requested but was found to contain a reference to a header ﬁle that has been updated since the precompiled header was built. Since the precompiled header may no longer accurately represent the state of the corresponding header ﬁle, PC-lint Plus will terminate. To resolve the issue either rebuild the precompiled header ﬁle or remove the option to use the pre-compiled header.

333
error
cannot open 'ﬁle' for string in secure mode
A ’forbidden’ ﬁle was opened. Opening such a ﬁle is considered a security violation by a hosted implementation.

334
error
precompiled header failure: 'string'; skipping this module; consider deleting the PCH, 'string', and trying again
This message is given when the precompiled header ﬁle is missing, older than the original ﬁle, created by a previous incompatible version of PC-lint Plus, created using a diﬀerent target conﬁguration, or another issue that prevents the ﬁle from being loaded. The PCH ﬁle will be skipped. If this error is encountered, the PCH ﬁle should be deleted and reconstituted using the current version of PC-lint Plus with the same options that will be used when loading the ﬁle.

336
error
source ﬁle is not valid UTF-8
Source ﬁles are expected to be encoded as UTF-8 text or UTF-16 text. The provided source ﬁle was presumed to contain UTF-8 text but an invalid byte sequence was encountered.

337
error
unable to read ﬁle 'ﬁle': detail
This message is given when the internal ﬁle information inside the precompiled header does not match its contents.

338
error
precompiled header error: string; skipping this module; consider examining include path options and trying again
This error indicates that there was an inconsistency in the way the precompiled header ﬁle was created and the way it is being used that prevents it from being loaded. The details of the issue are provided in the message text.

339
error
precompiled header for 'string' was not created due to errors
Precompiled header ﬁle creation was requested but an error occurred during the processing of a precompiled header candidate ﬁle that rendered the corresponding AST information unsuitable for use in a precompiled header ﬁle.

340
error
query assertion condition 'string' failed

365
error
command pipe error: string
An error has occurred while processing a request related to a command pipe program. The details of the error are speciﬁed in the message in ’string’.

366
error
regex error: string
An invalid regular expression has been used with the -cond option. The speciﬁc error is provided in ’string’.

367
error
maximum hook recursion depth (integer levels) reached
A limit has been reached on the number of recursively executing hooks. The limit that was reached is speciﬁed by ’integer’.

368
error
invalid conditional expression: string
An invalid conditional expression has been provided to the -cond option. The speciﬁc error is provided in the text of the message.

369
error
hook ﬁeld error while processing 'string': string
An invalid ﬁeld name was provided in a hook ﬁeld speciﬁer or an AST walk action was attempted on a non-walkable hook ﬁeld.

370
error
options executed within a module cannot invoke additional modules
An attempt was made to process a new module from within the module being processed. For example, a lint comment might contain an -indirect option resulting in the processing of options from a .lnt ﬁle. If this indirect ﬁle contains the name of a module to process, the module will not be opened and this message will be issued instead. Processing will then continue normally for the current module.

373
error
lint comments cannot appear after a #include directive on the same line
A lint comment appeared on the same line as an #include directive. Such usage is not currently supported and the lint comment will be ignored. Either place the lint comment before the #include directive, on the next line, or inside the ﬁle being included.

374
error
C++ module import 'string' not found

375
error
C++ module import 'string' could not be loaded

398
error
fatal error (requested by option): 'string'
A suppressible fatal error was requested through the use of the option -fatal_error. See also 399 .

399
error
fatal error (requested by option): 'string'
An unsuppressible fatal error was requested through the use of the option +fatal_error. See also 398 .

401
warning
symbol symbol not previously declared static
The indicated symbol declared static was previously declared without the static storage class. This is technically a violation of the ANSI/ISO standard. Some compilers will accept this situation without complaint and regard the symbol as static.
Supports AUTOSAR17 Rule M3-3-2
Supports AUTOSAR19 Rule M3-3-2
Supports CERT C DCL36-C - Do not declare an identiﬁer with conﬂicting linkage classiﬁcations
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2004 Rule 8.11 - The static storage class speciﬁer shall be used in deﬁnitions and declarations of objects and functions that have internal linkage.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3
Supports MISRA C++:2008 Rule 3-3-2 - If a function has internal linkage then all re-declarations shall include the static storage class speciﬁer.

402
warning
static function/variable symbol not deﬁned
The named symbol was declared as a static function in the current module and was referenced but was not deﬁned (in the module).

404
warning
deﬁnition of type starts in 'ﬁle' but ends in 'ﬁle'
A struct (or union or enum) deﬁnition was started within a header ﬁle but was not completed within the same header ﬁle.

407
warning
inconsistent use of tag symbol
A tag speciﬁed as a union, struct or enum was respeciﬁed as being one of the other two in the same module. For example:

struct tag *p; 
union tag *q;

will elicit this message.
Supports MISRA C 2004 Rule 5.4 - A tag name shall be a unique identiﬁer.
Supports MISRA C 2012 Rule 5.7 - A tag name shall be a unique identiﬁer
Supports MISRA C:2023 Rule 5.7 - A tag name shall be a unique identiﬁer
Supports MISRA C:2025 Rule 5.7

408
warning
case expression type (type) diﬀers from switch expression type (type)
The expression within a case does not agree exactly with the type within the switch expression. For example, an enumerated type is matched against an int.

409
warning
integer base for subscript operator is suspicious
An expression of the form i[...] was encountered where i is an integral expression. This could be legitimate depending on the subscript operand. For example, if i is an int and a is an array then i[a] is legitimate but unusual. If this is your coding style, suppress this message.
Supports CERT C ARR00-C - Understand how arrays work
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports CWE-129 - Improper Validation of Array Index

410
warning
size_t not what was expected from fzl and/or fzu, using type
This warning is issued if you had previously attempted to set the type of sizeof by use of the options +fzl , -fzl , or -fzu , and a later size_t declaration contradicts the setting. This usually means you are attempting to lint programs for another system using header ﬁles for your own system. If this is the case we suggest you create a directory housing header ﬁles for that foreign system, alter size_t within that directory, and lint using that directory.

411
warning
ptrdiﬀ_t not what was expected from fdl option, using type
This warning is issued if you had previously attempted to set the type of pointer diﬀerences by use of the fdl option and a later ptrdiff_t declaration contradicts the setting. See suggestion in Error Message 410 .

413
warning
likely use of null pointer symbol
From information gleaned from earlier statements, it appears likely that a null pointer (a pointer whose value is 0) has been used in a context where null pointers are inappropriate. Information leading to this determination is provided as a series of supplemental messages. See also message 613 .
Supports AUTOSAR19 Rule A5-3-2
Supports CERT C EXP34-C - Do not dereference null pointers
Supports CERT C ARR00-C - Understand how arrays work
Supports CERT C ARR30-C - Do not form or use out-of-bounds pointers or array subscripts
Supports CERT C MEM11-C - Do not assume inﬁnite heap space
Supports CERT C API00-C - Functions should validate their parameters
Supports CERT C MSC19-C - For functions that return an array, prefer returning an empty array over a null value
Supports CERT C POS54-C - Detect and handle POSIX library errors
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports CWE-123 - Write-what-where Condition
Supports CWE-125 - Out-of-bounds Read
Supports CWE-126 - Buﬀer Over-read
Supports CWE-127 - Buﬀer Under-read
Supports CWE-129 - Improper Validation of Array Index
Supports CWE-252 - Unchecked Return Value
Supports CWE-253 - Incorrect Check of Function Return Value
Supports CWE-391 - Unchecked Error Condition
Supports CWE-476 - NULL Pointer Dereference
Supports CWE-690 - Unchecked Return Value to NULL Pointer Dereference
Supports CWE-786 - Access of Memory Location Before Start of Buﬀer
Supports CWE-787 - Out-of-bounds Write
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

414
warning
possible division by zero
The second argument to either the division operator (/) or the modulus operator (%) may be zero. Information is taken from earlier statements including assignments, initialization and tests. See Chapter 8 Value Tracking .
Supports AUTOSAR17 Rule A5-5-1
Supports AUTOSAR19 Rule A5-6-1
Supports CWE-369 - Divide By Zero
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

415
warning
likely out of bounds pointer access: excess of integer byte(s)
An out-of-bounds pointer was likely accessed. The parameter integer gives some idea how far out of bounds the pointer may be, measured in bytes. For example:

int a[10]; 
a[10] = 0;

results in a message containing the phrase ’excess of 4 bytes’ if the size of int is 4. See Chapter 8 Value Tracking .
Supports AUTOSAR17 Rule M5-0-16
Supports AUTOSAR17 Rule A5-2-5
Supports AUTOSAR19 Rule M5-0-16
Supports AUTOSAR19 Rule A5-2-5
Supports CERT C ARR30-C - Do not form or use out-of-bounds pointers or array subscripts
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports CWE-123 - Write-what-where Condition
Supports CWE-125 - Out-of-bounds Read
Supports CWE-126 - Buﬀer Over-read
Supports CWE-127 - Buﬀer Under-read
Supports CWE-129 - Improper Validation of Array Index
Supports CWE-786 - Access of Memory Location Before Start of Buﬀer
Supports CWE-787 - Out-of-bounds Write
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 18.1 - A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
Supports MISRA C:2023 Rule 18.1 - A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
Supports MISRA C:2025 Rule 18.1
Supports MISRA C++:2008 Rule 5-0-16 - A pointer operand and any pointer resulting from pointer arithmetic using that operand shall both address elements of the same array.
Supports MISRA C++:2023 Rule 8.7.1 - Pointer arithmetic shall not form an invalid pointer

416
warning
likely creating out-of-bounds pointer: excess of integer byte(s)
An out-of-bounds pointer was created. See message 415 for a description of the integer parameter. integer and string. For example:

int a[10]; 
  ... 
f( a + 11 );

Here, an illicit pointer value is created and is ﬂagged as such by PC-lint Plus. Note that the pointer a+10 is not considered by PC-lint Plus to be the creation of an out-of-bounds pointer. This is because ANSI/ISO C explicitly allows pointing just beyond an array. Access through a+10, however, as in *(a+10) or the more familiar a[10], would be considered erroneous but in that case message 415 would be issued. See Chapter 8 Value Tracking .
Supports AUTOSAR17 Rule M5-0-16
Supports AUTOSAR17 Rule A5-2-5
Supports AUTOSAR19 Rule M5-0-16
Supports AUTOSAR19 Rule A5-2-5
Supports CERT C EXP08-C - Ensure pointer arithmetic is used correctly
Supports CERT C ARR30-C - Do not form or use out-of-bounds pointers or array subscripts
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports CWE-123 - Write-what-where Condition
Supports CWE-125 - Out-of-bounds Read
Supports CWE-126 - Buﬀer Over-read
Supports CWE-127 - Buﬀer Under-read
Supports CWE-129 - Improper Validation of Array Index
Supports CWE-468 - Incorrect Pointer Scaling
Supports CWE-786 - Access of Memory Location Before Start of Buﬀer
Supports CWE-787 - Out-of-bounds Write
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 18.1 - A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
Supports MISRA C:2023 Rule 18.1 - A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
Supports MISRA C:2025 Rule 18.1
Supports MISRA C++:2008 Rule 5-0-16 - A pointer operand and any pointer resulting from pointer arithmetic using that operand shall both address elements of the same array.
Supports MISRA C++:2023 Rule 8.7.1 - Pointer arithmetic shall not form an invalid pointer

417
warning
integral constant 'string' has precision integer which is longer than long long int
The longest possible integer is by default 8 bytes (see the +fll ﬂag and then the -sll# option). An integral constant was found to be even larger than such a quantity. For example: 0xFFFF0000FFFF0000F requires 68 bits and would by default elicit this message. string is the token in error, and integer is the binary precision.

418
warning
passing null pointer to function symbol, context
A NULL pointer is being passed to a function identiﬁed by symbol. The argument in question is given by context. The function is either a library function designed not to receive a NULL pointer or a user function dubbed so via the option -function or -sem . See Section 9.1 Function Mimicry (-function) and Section 9.2.1 Possible Semantics .
Supports CERT C EXP34-C - Do not dereference null pointers
Supports CERT C MSC19-C - For functions that return an array, prefer returning an empty array over a null value
Supports CWE-476 - NULL Pointer Dereference
Supports CWE-690 - Unchecked Return Value to NULL Pointer Dereference
Supports MISRA C 2004 Rule 20.3 - The validity of values passed to library functions shall be checked.
Supports MISRA C 2012 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2023 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2025 Dir 4.11

419
warning
apparent data overrun for function symbol, string (size=string) exceeds string (size=string)
This message is for data transfer functions such as memcpy, strcpy, fgets, etc. when the size indicated by the ﬁrst cited argument (or arguments) exceeds the size of the buﬀer area cited by the second. The message may also be issued for user functions via the -function option. See Section 9.1 Function Mimicry (-function) and Section 9.2.1 Possible Semantics .
Supports CERT C ARR38-C - Guarantee that library functions do not form invalid pointers
Supports CERT C MSC19-C - For functions that return an array, prefer returning an empty array over a null value
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports CWE-121 - Stack-based Buﬀer Overﬂow
Supports CWE-123 - Write-what-where Condition
Supports CWE-125 - Out-of-bounds Read
Supports CWE-126 - Buﬀer Over-read
Supports CWE-129 - Improper Validation of Array Index
Supports CWE-805 - Buﬀer Access with Incorrect Length Value
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2004 Rule 20.3 - The validity of values passed to library functions shall be checked.
Supports MISRA C 2012 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C 2012 AMD1 Rule 21.17 - Use of the string handling functions from <string.h> shall not result in accesses beyond the bounds of the objects referenced by their pointer parameters
Supports MISRA C 2012 AMD1 Rule 21.18 - The size_t argument passed to any function in <string.h> shall have an appropriate value
Supports MISRA C:2023 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 21.17 - Use of the string handling functions from <string.h> shall not result in accesses beyond the bounds of the objects referenced by their pointer parameters
Supports MISRA C:2023 Rule 21.18 - The size_t argument passed to any function in <string.h> shall have an appropriate value
Supports MISRA C:2025 Dir 4.11
Supports MISRA C:2025 Rule 1.3
Supports MISRA C:2025 Rule 21.17
Supports MISRA C:2025 Rule 21.18
Supports MISRA C++:2023 Rule 8.7.1 - Pointer arithmetic shall not form an invalid pointer

420
warning
apparent access beyond array for function symbol, string (size=string) exceeds string (size=string)
This message is issued for several library functions (such as fwrite, memcmp, etc.) wherein there is an apparent attempt to access more data than exist. For example, if the length of data speciﬁed in the fwrite call exceeds the size of the data speciﬁed. The function is speciﬁed by symbol and the arguments are identiﬁed by argument number. See Section 9.1 Function Mimicry (-function) and Section 9.2.1 Possible Semantics .
Supports CERT C ARR38-C - Guarantee that library functions do not form invalid pointers
Supports CERT C MSC19-C - For functions that return an array, prefer returning an empty array over a null value
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports CWE-121 - Stack-based Buﬀer Overﬂow
Supports CWE-123 - Write-what-where Condition
Supports CWE-125 - Out-of-bounds Read
Supports CWE-126 - Buﬀer Over-read
Supports CWE-127 - Buﬀer Under-read
Supports CWE-129 - Improper Validation of Array Index
Supports CWE-805 - Buﬀer Access with Incorrect Length Value
Supports MISRA C 2004 Rule 20.3 - The validity of values passed to library functions shall be checked.
Supports MISRA C 2012 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C 2012 AMD1 Rule 21.17 - Use of the string handling functions from <string.h> shall not result in accesses beyond the bounds of the objects referenced by their pointer parameters
Supports MISRA C 2012 AMD1 Rule 21.18 - The size_t argument passed to any function in <string.h> shall have an appropriate value
Supports MISRA C:2023 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2023 Rule 21.17 - Use of the string handling functions from <string.h> shall not result in accesses beyond the bounds of the objects referenced by their pointer parameters
Supports MISRA C:2023 Rule 21.18 - The size_t argument passed to any function in <string.h> shall have an appropriate value
Supports MISRA C:2025 Dir 4.11
Supports MISRA C:2025 Rule 21.17
Supports MISRA C:2025 Rule 21.18
Supports MISRA C++:2023 Rule 8.7.1 - Pointer arithmetic shall not form an invalid pointer

421
warning
caution – function symbol is considered dangerous
This message is issued (by default) for the built-in function gets. This function is considered dangerous because there is no mechanism to ensure that the buﬀer provided as ﬁrst argument will not overﬂow. Numerous exploits and vulnerabilities are attributed to the gets function including the Morris worm, which exploited the use of the gets function in the ﬁngered program of target machines. Through the -function option or the dangerous semantic (304 dangerous ), the user may designate other functions as dangerous. See also -deprecate .
Supports CERT C STR31-C - Guarantee that storage for strings has suﬃcient space for character data and the null terminator
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports CWE-120 - Buﬀer Copy without Checking Size of Input (‘Classic Buﬀer Overﬂow’)
Supports CWE-121 - Stack-based Buﬀer Overﬂow
Supports CWE-122 - Heap-based Buﬀer Overﬂow
Supports CWE-123 - Write-what-where Condition
Supports CWE-125 - Out-of-bounds Read
Supports CWE-193 - Oﬀ-by-one Error
Supports CWE-242 - Use of Inherently Dangerous Function
Supports CWE-676 - Use of Potentially Dangerous Function

422
warning
passing to function symbol a negative value (integer) context
An integral value that appears to be negative is being passed to a function that is expecting only positive values for a particular argument. The message contains the name of the function (symbol), the questionable value (integer) and the argument number (context). The function may be a standard library function designed to accept only positive values such as malloc or memcpy (third argument), or may have been identiﬁed by the user as such through the -function or -sem options.

The parameter type may in fact be unsigned. Thus:

void *malloc(unsigned); 
void f() { 
   int n = -1; 
   int *p; 
   p = malloc(n);           // warning 422 
}

will result in the warning indicated.
Supports CWE-687 - Function Call With Incorrectly Speciﬁed Argument Value
Supports MISRA C 2004 Rule 20.3 - The validity of values passed to library functions shall be checked.
Supports MISRA C 2012 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C 2012 AMD1 Rule 21.18 - The size_t argument passed to any function in <string.h> shall have an appropriate value
Supports MISRA C:2023 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2023 Rule 21.18 - The size_t argument passed to any function in <string.h> shall have an appropriate value
Supports MISRA C:2025 Dir 4.11
Supports MISRA C:2025 Rule 21.18

423
warning
assignment to custodial pointer symbol likely creates memory leak
An assignment was made to a pointer variable (designated by symbol), which appeared to already be holding the address of an allocated object that had not been freed. The allocation of memory that is not freed is considered a memory leak. For example:

void f() { 
   int* custodian = (int*)malloc(sizeof(int)); 
   int* ptr; 
   int n = 0; 
 
   custodian = &n;   // warning 423 
   ptr = &n;        // Okay 
}

See also message 810 .
Supports CWE-772 - Missing Release of Resource after Eﬀective Lifetime

424
warning
string is not appropriate for deallocating string
This message indicates that a deallocation (free, delete, or delete[]) as speciﬁed by the ﬁrst string parameter is inappropriate for the data being freed. [?, Item 5]

The kind of data (speciﬁed by the second string parameter) is one or more of: malloc, new, new[], static, auto, member, modified or constant. These have the meanings as described below:

malloc: data is data obtained from a call to malloc, calloc or realloc.
new and new[]: data is data derived from calls to new.
static: data is either static data within a function or external data.
auto: data is non-static data in a function.
member: data is a component of a structure (and hence can’t be independently freed).
modified: data is the result of applying pointer arithmetic to some other pointer. E.g.
```
p = malloc(100); 
free( p+1 ); // warning
```
p+1 is considered modiﬁed.
constant data is the result of casting a constant to a pointer. E.g.
```
int *p = (int *) Ox80002; 
free(p); // warning
```

See also message 673 .
Supports AUTOSAR17 Rule A18-5-3
Supports AUTOSAR19 Rule A18-5-3
Supports CERT C MEM34-C - Only free memory allocated dynamically
Supports CWE-404 - Improper Resource Shutdown or Release
Supports CWE-590 - Free of Memory not on the Heap
Supports CWE-762 - Mismatched Memory Management Routines
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 22.2 - A block of memory shall only be freed if it was allocated by means of a Standard Library function
Supports MISRA C:2023 Rule 22.2 - A block of memory shall only be freed if it was allocated by means of a Standard Library function
Supports MISRA C:2025 Rule 22.2

425
warning
'message' in processing semantic 'string' at token 'string'
This warning is issued when a syntax error is encountered while processing a semantic option (-sem ). The ’message’ depends upon the error. The ﬁrst ’string’ represents the portion of the semantic being processed. The second ’string’ denotes the token being scanned when the error is ﬁrst noticed.

426
warning
call to function symbol violates semantic 'string'
This warning message is issued when a user semantic (as deﬁned by -sem ) is violated. ’string’ is the subportion of the semantic that was violated. For example:

//lint -sem( f, 1n > 10 && 2n > 10 ) 
void f( int, int ); 
... 
   f( 2, 20 );

results in the message:

Call to function 'f(int, int)' violates semantic '(1n>10)'

Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports CWE-176 - Improper Handling of Unicode Encoding
Supports CWE-562 - Return of Stack Variable Address
Supports CWE-686 - Function Call With Incorrect Argument Type
Supports CWE-687 - Function Call With Incorrectly Speciﬁed Argument Value
Supports CWE-785 - Use of Path Manipulation Function without Maximum-sized Buﬀer
Supports MISRA C 2012 AMD1 Rule 21.13 - Any value passed to a function in <ctype.h> shall be representable as an unsigned char or be the value EOF
Supports MISRA C:2023 Rule 21.13 - Any value passed to a function in <ctype.h> shall be representable as an unsigned char or be the value EOF
Supports MISRA C:2025 Rule 21.13

427
warning
// comment continued via back-slash
The line that starts a C++ style comment ends with a back-slash causing the next line to be absorbed into the comment, which may not be the intended behavior. If you really intend the next line to be a comment, the line should be started with its own double slash (//) or the entire region replaced with a block comment.
Supports AUTOSAR17 Rule A2-8-1
Supports AUTOSAR19 Rule A2-7-1
Supports CERT C MSC04-C - Use comments consistently and in a readable fashion
Supports MISRA C 2012 Rule 3.2 - Line-splicing shall not be used in // comments
Supports MISRA C:2023 Rule 3.2 - Line-splicing shall not be used in // comments
Supports MISRA C:2025 Rule 3.2
Supports MISRA C++:2023 Rule 5.7.3 - Line-splicing shall not be used in // comments

428
warning
likely indexing before the beginning of an allocation
A negative integer was added to an array or to a pointer to an allocated area (allocated by malloc, operator new, etc.) This message is not given for pointers whose origin is unknown since a negative subscript is, in general, legal.

The addition could have occurred as part of a subscript operation or as part of a pointer arithmetic operation.
Supports CWE-124 - Buﬀer Underwrite (‘Buﬀer Underﬂow’)
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 18.1 - A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
Supports MISRA C:2023 Rule 18.1 - A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
Supports MISRA C:2025 Rule 18.1
Supports MISRA C++:2023 Rule 8.7.1 - Pointer arithmetic shall not form an invalid pointer

429
warning
custodial pointer symbol likely not string nor returned
A pointer of auto storage class was allocated storage, which was neither freed nor returned to the caller. This represents a "memory leak". A pointer is considered custodial if it uniquely points to the storage area. It is not considered custodial if it has been copied. Thus:

int *p = new int[20];  // p is a custodial pointer 
int *q = p;           // p is no longer custodial 
p = new int[20];       // p again becomes custodial 
q = p + 0;            // p remains custodial

Here p does not lose its custodial property by merely participating in an arithmetic operation.

A pointer can lose its custodial property by passing the pointer to a function. If the parameter of the function is typed pointer to const or if the function is a library function, that assumption is not made. For example

p = malloc(10); 
strcpy (p, "hello");

Then p still has custody of storage allocated.

It is possible to indicate via semantic options that a function will take custody of a pointer. See 9.2.1 custodial(i) . It is possible to declare that no functions take custody other than those speciﬁed in a -sem option. See also Flag ffc (Functions take custody).
Supports CERT C ARR00-C - Understand how arrays work
Supports CERT C MEM12-C - Consider using a goto chain when leaving a function on error when using and releasing resources
Supports CERT C MEM31-C - Free dynamically allocated memory when no longer needed
Supports CERT C FIO42-C - Close ﬁles when they are no longer needed
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports CWE-129 - Improper Validation of Array Index
Supports CWE-401 - Missing Release of Memory after Eﬀective Lifetime
Supports CWE-404 - Improper Resource Shutdown or Release
Supports CWE-415 - Double Free
Supports CWE-459 - Incomplete Cleanup
Supports CWE-771 - Missing Reference to Active Allocated Resource
Supports CWE-772 - Missing Release of Resource after Eﬀective Lifetime
Supports CWE-773 - Missing Reference to Active File Descriptor or Handle
Supports CWE-775 - Missing Release of File Descriptor or Handle after Eﬀective Lifetime
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C 2012 Rule 22.1 - All resources obtained dynamically by means of Standard Library functions shall be explicitly released
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Rule 22.1 - All resources obtained dynamically by means of Standard Library functions shall be explicitly released
Supports MISRA C:2025 Dir 4.13
Supports MISRA C:2025 Rule 22.1

430
warning
use of '@/:' is non-standard
Some compilers for embedded systems have a declaration syntax that speciﬁes a location in place of an initial value for a variable. For example:

int x @ 0x2000;

speciﬁes that variable x is explicitly located at memory address 0x2000. By default, this syntax is only recognized when the address is introduced by ‘@’. If the fce ﬂag is enabled, then this extension will also be recognized when introduced by ‘:’.

This message is a reminder that this syntax is non-standard. If you are using this syntax deliberately, this message can be suppressed.

432
warning
suspicious argument to dynamic allocation function
The following pattern was detected:

malloc( strlen(e+1) )

where e is some expression. This is suspicious because it closely resembles the commonly used pattern:

malloc( strlen(e)+1 )

If you really intended to use the ﬁrst pattern then an equivalent expression that will not raise this error is:

malloc( strlen(e)-1 )

Supports CWE-687 - Function Call With Incorrectly Speciﬁed Argument Value

433
warning
allocated area not large enough for pointer (integer vs string)
An allocation was assigned to a pointer whose reach extends beyond the area that was allocated. This would usually happen only with library allocation routines such as malloc and calloc. For example:

int *p = malloc(1);

This message is also provided for user-declared allocation functions. For example, if a user’s own allocation function is provided with the following semantic:

-sem(ouralloc,@P==malloc(1n))

We would report the same message. Please note that it is necessary to designate that the returned area is freshly allocated (ala malloc).

This message is always given in conjunction with the more general Informational Message 826 .
Supports CERT C MEM35-C - Allocate suﬃcient memory for an object
Supports CWE-131 - Incorrect Calculation of Buﬀer Size
Supports CWE-190 - Integer Overﬂow or Wraparound
Supports CWE-467 - Use of sizeof() on a Pointer Type
Supports CWE-680 - Integer Overﬂow to Buﬀer Overﬂow
Supports CWE-789 - Memory Allocation with Excessive Size Value

434
warning
white space ignored between back-slash and new-line
According to the C and C++ standards, any back-slash followed immediately by a new-line results in the deletion of both characters. For example:

#define A \ 
      34

deﬁnes A to be 34. If a blank or tab intervenes between the back-slash and the new-line then according to a strict interpretation of the standard you have deﬁned A to be a back-slash followed by blank or tab. But this blank is invisible to the naked eye and hence could lead to confusion. Worse, some compilers silently ignore the white-space and the program becomes non-portable.

You should never deliberately place a blank at the end of a line and any such blanks should be removed. If you really need to deﬁne a macro to be back-slash blank you can use a comment as in:

#define A \  /* commentary */

435
warning
integral constant 'string' has precision integer, use +ﬂl to enable long long
An integer constant was found that had a precision that was too large for a long but would ﬁt within a long long. Yet the +fll ﬂag that enables the long long type was not set.

Check the sizes that you speciﬁed for long (-sl# ) and for long long (-sll# ) and make sure they are correct. Turn on +fll if your compiler supports long long. Otherwise use smaller constants.

436
warning
preprocessor directive in invocation of macro
A function like macro was invoked whose arguments extended for multiple lines, which included preprocessor statements. This is almost certainly an error brought about by a missing right parenthesis.

By the rules of the C and C++ standards, the result of this behavior is undeﬁned. For this reason some compilers treat the apparent preprocessor directive as a directive. However, avoiding this construct is recommended for portability.
Supports AUTOSAR17 Rule M16-0-5
Supports AUTOSAR19 Rule M16-0-5
Supports CERT C PRE32-C - Do not use preprocessor directives in invocations of function-like macros
Supports MISRA C 2004 Rule 19.9 - Arguments to a function-like macro shall not contain tokens that look like preprocessing directives.
Supports MISRA C 2012 Rule 20.6 - Tokens that look like a preprocessing directive shall not occur within a macro argument
Supports MISRA C:2023 Rule 20.6 - Tokens that look like a preprocessing directive shall not occur within a macro argument
Supports MISRA C:2025 Rule 20.6
Supports MISRA C++:2008 Rule 16-0-5 - Arguments to a function-like macro shall not contain tokens that look like preprocessing directives.
Supports MISRA C++:2023 Rule 19.3.5 - Tokens that look like a preprocessing directive shall not occur within a macro argument

437
warning
passing a class/struct to an elliptic argument
A struct or class is being passed to a function at a parameter position identiﬁed by an ellipsis. For example:

void g() { 
   struct A { int a; } x; 
   void f( int, ... ); 
   f( 1, x ); 
   ... 
}

This is suﬃciently unusual that it is worth pointing out in the likelihood that this is unintended. The situation becomes more severe in the case of a non-POD struct [10]. In this case the behavior is considered undeﬁned.
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

438
warning
last value assigned to symbol not used
A value had been assigned to a variable that was not subsequently used. The message is issued either at a return statement or at the end of a block when the variable goes out of scope. For example, consider the following function:

void f( int n ) { 
   int x = 0, y = 1; 
   if( n > 0 ) { 
      int z; 
      z = x + y; 
      if( n > z ) { x = 3; return; } 
      z = 12; 
   } 
}

Here we can report that x was assigned a value that had not been used by the time the return statement had been encountered. We also report that the most recently assigned value to z is unused at the point that z goes out of scope. See also Informational message 838 and ﬂags -fiw and -fiz .
Supports AUTOSAR17 Rule A0-1-1
Supports AUTOSAR17 Rule M0-1-9
Supports AUTOSAR19 Rule A0-1-1
Supports AUTOSAR19 Rule M0-1-9
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CERT C MSC13-C - Detect and remove unused values
Supports CWE-561 - Dead Code
Supports CWE-563 - Assignment to Variable without Use
Supports MISRA C 2012 Rule 2.2 - A project shall not contain dead code
Supports MISRA C:2023 Rule 2.2 - A project shall not contain dead code
Supports MISRA C:2025 Rule 2.2
Supports MISRA C++:2008 Rule 0-1-6 - A project shall not contain instances of non-volatile variables being given values that are never subsequently used.
Supports MISRA C++:2008 Rule 0-1-9 - There shall be no dead code.
Supports MISRA C++:2023 Rule 0.1.1 - A value should not be unnecessarily written to a local object

440
warning
for statement condition is inconsistent with modiﬁcation variable symbol
A for clause has a suspicious structure. The loop variable, as determined by an examination of the 3rd for clause expression, is not tested in the 2nd for clause expression. For example:

for( i = 0; i < 10; j++ ) 
   ...

would draw this complaint since the ’i’ of the 2nd expression does not match the ’j’ of the third expression.
Supports CERT C MSC21-C - Use robust loop termination conditions
Supports MISRA C 2004 Rule 13.5 - The three expressions of a for statement shall be concerned only with loop control.

442
warning
for statement condition and increment directions are inconsistent for variable symbol
A for clause was encountered that appeared to have a parity problem. For example:

for( i = 0; i < 10; i-- ) 
   ...

Here the test for i less than 10 seems inconsistent with the 3rd expression of the for clause, which decreases the value of i. This same message would be given if i were being increased by the 3rd expression and was being tested for being greater than some value in the 2nd expression.
Supports CERT C MSC21-C - Use robust loop termination conditions

443
warning
for statement initializer is inconsistent with modiﬁcation variable symbol
A for clause has a suspicious structure. The loop variable, as determined by an examination of the 3rd for clause expression, does not match the variable that is initialized in the 1st expression. For example:

for( ii = 0; i < 10; i++ ) 
   ...

would draw this complaint since the ’ii’ of the 1st expression does not match the ’i’ of the third expression.
Supports CERT C MSC21-C - Use robust loop termination conditions
Supports MISRA C 2004 Rule 13.5 - The three expressions of a for statement shall be concerned only with loop control.

444
warning
for statement condition tests incremented/decremented pointer symbol for null
The following kind of situation has been detected:

for( ... ; p == NULL; p++ ) 
    ...

A loop variable being incremented or decremented would not normally be checked to see if it is NULL. This is more likely a programmer error.
Supports CERT C EXP34-C - Do not dereference null pointers
Supports CERT C MSC21-C - Use robust loop termination conditions
Supports CWE-476 - NULL Pointer Dereference
Supports CWE-690 - Unchecked Return Value to NULL Pointer Dereference

445
warning
reuse of for loop variable symbol
A for loop nested within another for loop employed the same loop variable. For example:

for( i = 0; i < 100; i++ ) { 
   for( i = 0; i < n; i++ ) { ... } 
}

Supports CERT C MSC21-C - Use robust loop termination conditions

446
warning
side-eﬀect in initializer list
An initializer containing a side eﬀect can be potentially troublesome. For example, the code:

void f( int i ) { 
   int a[2] = {i++, i++}; 
 }

The values of the array elements are unspeciﬁed because the order of evaluation is unspeciﬁed by the C standard.
Supports MISRA C 2012 Rule 13.1 - Initializer lists shall not contain persistent side eﬀects
Supports MISRA C:2023 Rule 13.1 - Initializer lists shall not contain persistent side eﬀects
Supports MISRA C:2025 Rule 13.1

447
warning
extraneous whitespace found in include directive for ﬁle ﬁle; Opening ﬁle ﬁle
A named ﬁle was found to contain either leading or trailing whitespace in the #include directive. While legal, the ISO Standards allow compilers to deﬁne how ﬁles are speciﬁed or the header is identiﬁed, including the appearance of whitespace characters immediately after the < or opening " or before the > or closing ". Since ﬁlenames tend not to contain leading or trailing whitespace, PC-lint Plus ignores the (apparently) extraneous characters and processes the directive as though the characters were never given. The use of a -efile option on either ﬁle for this message will cause Lint to process #include’s with whitespace intact.

448
warning
possible access integer bytes beyond null terminator by 'operator'
Accessing past the terminating nul character is often an indication of a programmer error. For example:

char buf[20]; 
strcpy( buf, "a" ); 
char c = buf[4]; // legal but suspect

Although buf has 20 characters, after the strcpy, there would be only two that the programmer would normally be interested in.

449
warning
memory was likely previously deallocated
A pointer variable (designated in the message) was freed or deleted in an earlier statement.
Supports CERT C MEM00-C - Allocate and free memory in the same module, at the same level of abstraction
Supports CERT C MEM30-C - Do not access freed memory
Supports CWE-415 - Double Free
Supports CWE-416 - Use After Free
Supports CWE-666 - Operation on Resource in Wrong Phase of Lifetime
Supports CWE-672 - Operation on a Resource after Expiration or Release
Supports CWE-758 - Reliance on Undeﬁned, Unspeciﬁed, or Implementation-Deﬁned Behavior
Supports CWE-825 - Expired Pointer Dereference
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C 2012 Rule 22.2 - A block of memory shall only be freed if it was allocated by means of a Standard Library function
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 22.2 - A block of memory shall only be freed if it was allocated by means of a Standard Library function
Supports MISRA C:2025 Dir 4.13
Supports MISRA C:2025 Rule 1.3
Supports MISRA C:2025 Rule 22.2
Supports MISRA C++:2023 Rule 6.8.1 - An object shall not be accessed outside of its lifetime

450
warning
namespace symbol declared within an extern "C" region
A namespace was declared either with an extern "C" speciﬁer or within an extern "C" region. The ISO C++ standard leaves the eﬀects of such unspeciﬁed. If an extern "C" speciﬁcation is necessary for the declarations within the namespace, it should be inside the namespace rather than outside.

451
warning
header ﬁle 'string' repeatedly included but has no header guard
The ﬁle named in the message has already been included in the current module. Moreover, no mechanism to prevent multiple inclusion (such as an include guard or #pragma once) was detected. An include guard is one of:

#ifndef Name 
#define Name Value 
... 
#endif

#if !defined(X) 
#define X Value 
... 
#endif

with nothing but comments before and after this sequence and nothing but comments between the #if/#ifndef and the #define. Value is optional and may contain any expansion text if present. The macro Name must not be deﬁned when the header is included for the ﬁrst time.

This warning may also be accompanied by a 537 (repeated include header). Message 537 is often suppressed because if you are working with include guards it is not a helpful message. However, the message 451 should be left on in order to check the consistency of the include guards themselves.
Supports MISRA C 2004 Rule 19.15 - Precautions shall be taken in order to prevent the contents of a header ﬁle being included twice.
Supports MISRA C 2012 Dir 4.10 - Precautions shall be taken in order to prevent the contents of a header ﬁle being included more than once
Supports MISRA C:2023 Dir 4.10 - Precautions shall be taken in order to prevent the contents of a header ﬁle being included more than once
Supports MISRA C:2025 Dir 4.10

452
warning
type redeﬁnition with diﬀerent types type
A typedef symbol is being declared to be a diﬀerent type. This can be legal, especially with multiple modules, but is not good programming practice. It interferes with program legibility.

453
warning
function symbol, previously designated pure, reason symbol
A semantic option designated that the named function, symbol, is pure (lacking non-local side-eﬀects): see the pure semantic in Chapter 9 Semantics . However, an impurity was detected. Such impurities include calling a function through a function pointer, accessing a volatile variable, modifying a static variable or calling a function whose purity PC-lint Plus cannot verify. Reason describes which of these reasons apply and the second symbol parameter shows the related variable or function as appropriate.

Despite the inconsistency reported, the function will continue to be regarded as pure.

454
warning
mutex symbol locked without being unlocked
A mutex was locked without being subsequently unlocked in the same enclosing scope. For example:

#include <mutex> 
 
std::mutex my_mutex; 
int my_data = 0; 
 
void foo() { 
   my_mutex.lock(); 
   ++my_data; 
}  // 454: my_mutex not unlocked in foo()

The location of the lock operation is provided as a supplemental message.
Supports CERT C CON01-C - Acquire and release synchronization primitives in the same module, at the same level of abstraction
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C 2012 AMD4 Rule 22.16 - All mutex objects locked by a thread shall be explicitly unlocked by the same thread
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Rule 22.16 - All mutex objects locked by a thread shall be explicitly unlocked by the same thread
Supports MISRA C:2025 Dir 4.13
Supports MISRA C:2025 Rule 22.16

455
warning
mutex/locker symbol unlocked without being locked
A mutex was unlocked without previously being locked in the same enclosing scope. For example:

#include <mutex> 
 
std::mutex my_mutex; 
int my_data = 0; 
 
void foo() { 
   ++my_data; 
   my_mutex.unlock();  // 455: my_mutex not locked in foo() 
}

Supports CERT C CON01-C - Acquire and release synchronization primitives in the same module, at the same level of abstraction
Supports CWE-832 - Unlock of a Resource that is not Locked
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C 2012 AMD4 Rule 22.17 - No thread shall unlock a mutex or call cnd_wait() or cnd_timedwait() for a mutex it has not locked before
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Rule 22.17 - No thread shall unlock a mutex or call cnd_wait() or cnd_timedwait() for a mutex it has not locked before
Supports MISRA C:2025 Dir 4.13
Supports MISRA C:2025 Rule 22.17

456
warning
multiple 'string' execution paths are being combined with diﬀerent lock states
The lock state of one or more mutexes could not be determined due to conditional lock state changes whose eﬀect persists after the scope of the condition. This can occur if a mutex is locked without being unlocked in a conditional statement. For example:

#include <mutex> 
 
std::mutex my_mutex; 
int my_data = 0; 
 
void foo(int i) { 
   if (i == 1) { my_mutex.lock(); }  // 456 
   /* ... */ 
}

Mutex lock and unlock operations should be balanced within the same scope. String is one of break, case, conditional, if, iteration, switch, or try indicating the type of combined execution path responsible for the inconsistent lock state.
Supports CERT C CON01-C - Acquire and release synchronization primitives in the same module, at the same level of abstraction
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2025 Dir 4.13

457
warning
variable 'name' is 'read/written/atomically read/atomically written' in function 'name' of thread 'name' at location which is unprotected with the 'read/write/atomic read/atomic write' in function 'name' of thread 'name' at location
A variable was accessed by two threads in an unsafe way outside of the protection of a mutex. An access of the same variable by two threads is considered to be unsafe unless:

Both accesses are reads, atomic reads, or a combination thereof.
Both accesses are atomic reads, atomic writes, or a combination thereof.

Any other combination of accesses to the same variable across threads requires acquisition of at least one common mutex by both threads before accessing the variable in either thread. For example, if one thread reads a variable and another thread writes to the same variable, both threads must perform their access while a common mutex is held. Note that it is not suﬃcient for only one of the pair of unsafe accesses to be protected by a mutex. A variable is assumed to be accessed for writing if it is passed to a function by non-const reference or used to initialize a non-const reference variable even if it is not modiﬁed through that reference. This message may be issued for accesses by the same function if the function could execute concurrently.

The message includes the functions, and their corresponding threads, which access the variable, the location and type of access by each function, and the name of the variable that is accessed in an unsafe way. Supplemental messages provide the call path from each thread function and the mutexes held at each point as well as the mutexes held at the point of access.

This message is suppressed if inter-module thread analysis is disabled (see Inhibition of Thread Analysis ).
Supports CERT C CON32-C - Prevent data races when accessing bit-ﬁelds from multiple threads
Supports CERT C CON43-C - Do not allow data races in multithreaded code
Supports CERT C POS49-C - When data must be accessed by multiple threads, provide a mutex and guarantee no adjacent data is also accessed
Supports CWE-362 - Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’)
Supports CWE-366 - Race Condition within a Thread
Supports CWE-667 - Improper Locking
Supports MISRA C 2012 AMD4 Dir 5.1 - There shall be no data races between threads
Supports MISRA C:2023 Dir 5.1 - There shall be no data races between threads
Supports MISRA C:2025 Dir 5.1

459
warning
function 'name' whose address was taken has an unprotected 'read/write/atomic read/atomic write' access of variable 'name' in function 'name' at location
The speciﬁed function accesses a shared variable outside the protection of a locally acquired mutex and had its address taken. Additionally, the program appears to be multi-threaded by virtue of a call to a function with the thread_create semantic or the declaration of a function with the thread semantic. Supplemental messages provide the location(s) where the address of the function was taken and the call path from the function to the access of the shared variable, if applicable.

If a function’s address is taken, it is presumed that the locations from which the function may be called cannot be statically determined. As such, the function needs to have protected access to every shared variable that it accesses.

There are several remedies to such a message. If multiple threads can indeed access this function, then place a mutex lock in the function. If only one thread really accesses this function or if the access is guaranteed to be benign, then, after making sure this condition is commented in the code, the message may be suppressed for the function using the -estring option.

This message is suppressed if inter-module thread analysis is disabled (see Inhibition of Thread Analysis ).
Supports CWE-362 - Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’)
Supports CWE-667 - Improper Locking
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2025 Dir 4.13

460
warning
thread unsafe function 'name' is called while mutually unprotected in function 'name' of thread 'name' at location and function 'name' of thread 'name' at location
The function speciﬁed by the ﬁrst name parameter was designated as being thread_unsafe with the -sem option. It was being called by the speciﬁed functions within the speciﬁed threads. The identiﬁed calls were not made with the protection of a common mutex. Supplemental messages provide the call path to the function from the speciﬁed threads and the mutexes locked at the call points.

Calls to thread unsafe functions need to be protected by exclusive (non-shared) mutex locks if they are to be called by more than one thread.

461
warning
functions 'name' and 'name' of group 'name' are called mutually unprotected in function 'name' of thread 'name' at location and function 'name' of thread 'name' at location
Two functions with the same thread_unsafe group id are being called outside the protection of a common mutex. Functions speciﬁed with the same thread_unsafe group id are handled as if they manipulate the same static data and require the protection of exclusive (non-shared) mutex locks when called by multiple threads. Supplemental messages provide the call path to the function from the speciﬁed threads and the mutexes locked at the call points.

462
warning
function 'name' is called inconsistently with the 'thread_only|thread_not' semantic in function 'name' of thread 'name' at location
A thread is calling the function identiﬁed by the ﬁrst name parameter, either directly or indirectly. The called function has additionally been identiﬁed as a function that should not be called by this thread for one of the following reasons:

The thread_not semantic was applied to the function to indicate that the function should not be called by any thread.
The thread_not semantic was applied to the function with a list of threads that contains the thread calling the function.
The thread_only semantic was applied to the function with a list of threads that does not contain the thread calling the function.

The second message parameter speciﬁes the relevant semantic that had been attributed to the function. The calling function and associated thread are provided in the last two parameters. Supplemental messages provide the call graph of the function from the speciﬁed thread.

463
warning
could not parse 'string' as a strong type: string
This message is issued when a parse failure occurs when parsing a type speciﬁed with the -strong option. The ﬁrst string contains the type speciﬁcation that caused the error and the second string provides additional information about the error such as "unmatched right parenthesis".

464
warning
buﬀer arguments 'integer' and 'integer' in call to function symbol overlap
This is issued when we encounter a function argument expression used in such a way that there will be an attempt to copy its contents onto itself. E.g.

sprintf( s, "%s", s );

Supports AUTOSAR17 Rule M0-2-1
Supports AUTOSAR19 Rule M0-2-1
Supports CWE-687 - Function Call With Incorrectly Speciﬁed Argument Value
Supports MISRA C 2004 Rule 18.2 - An object shall not be assigned to an overlapping object.
Supports MISRA C 2012 Rule 19.1 - An object shall not be assigned or copied to an overlapping object
Supports MISRA C:2023 Rule 19.1 - An object shall not be assigned or copied to an overlapping object
Supports MISRA C:2025 Rule 19.1
Supports MISRA C++:2008 Rule 0-2-1 - An object shall not be assigned to an overlapping object.

466
warning
conversion to/from pointer to function with no prototype (context)
A pointer to a function without a prototype was assigned to or from another pointer to function. While assigning a pointer to function with a prototype, to one without a prototype is legal in ISO C, unexpected behavior may occur too easily. For example:

char *(*pf)(); 
char *strchr(const char *); 
void g() { 
   pf = strchr; // Msg 466 
   pf(12, 2);  // undefined behavior 
}

Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

473
warning
argument 'string' is of insuﬃcient length for array parameter symbol declared as type
This message is issued when a function declared with a constant-sized array parameter is passed an argument which can be determined, using Value Tracking, to either be null or to point to an area that is smaller than the size of the array. For example:

void init(unsigned char array[10]); 
 
void *malloc(unsigned); 
 
void foo() { 
   unsigned char array1[5]; 
   unsigned int array2[3]; 
   unsigned char *pc1 = malloc(8); 
   unsigned char *pc2 = (unsigned char *)array2; 
 
   init(array1);  // 473 - array1 is 5 bytes, init expects 10 
   init(pc1);     // 473 - pc1 points to 8 bytes (or is null) 
   init(pc2);     // Okay - assuming ints are 4 bytes or larger 
   init(0);       // 473 - null argument 
}

Supports CERT C MSC19-C - For functions that return an array, prefer returning an empty array over a null value
Supports MISRA C 2012 Rule 17.5 - The function argument corresponding to a parameter declared to have an array type shall have an appropriate number of elements
Supports MISRA C:2023 Rule 17.5 - The function argument corresponding to a parameter declared to have an array type shall have an appropriate number of elements
Supports MISRA C:2025 Rule 17.5

474
warning
constant switch condition 'string' not handled by switch
The condition of a switch was a constant expression, e.g. switch(7). Furthermore, there is no default case and no case statement that matches the constant expression. ’string’ contains the constant used as the switch condition.
Supports CERT C MSC01-C - Strive for logical completeness
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code

483
warning
switching on a boolean value
At least one standards organization has expressed the perspective, if the expression of a switch statement is boolean in nature, if-else should be used instead.
Supports AUTOSAR17 Rule M6-4-7
Supports AUTOSAR19 Rule M6-4-7
Supports MISRA C 2012 Rule 16.7 - A switch-expression shall not have essentially Boolean type
Supports MISRA C:2023 Rule 16.7 - A switch-expression shall not have essentially Boolean type
Supports MISRA C:2025 Rule 16.7
Supports MISRA C++:2008 Rule 6-4-7 - The condition of a switch statement shall not have bool type.
Supports MISRA C++:2023 Rule 7.0.1 - There shall be no conversion from type bool

484
warning
stringize operator followed by macro parameter followed by pasting operator
Due to order of evaluation issues, the mixing of stringizing and pasting operators, particularly when appearing in the order # parameter ##, results in unspeciﬁed behavior.
Supports MISRA C 2012 Rule 20.11 - A macro parameter immediately following a # operator shall not immediately be followed by a ## operator
Supports MISRA C:2023 Rule 20.11 - A macro parameter immediately following a # operator shall not immediately be followed by a ## operator
Supports MISRA C:2025 Rule 20.11
Supports MISRA C++:2023 Rule 19.3.2 - A macro parameter immediately following a # operator shall not be immediately followed by a ## operator

485
warning
duplicate partial/complete initialization of object element
In addition to the behavior being unspeciﬁed when the use of designated initializers results in duplicate object initialization, assigning to an array element or structure member more than once in an initializer is typically a logic error.
Supports MISRA C 2012 Rule 9.4 - An element of an object shall not be initialized more than once
Supports MISRA C:2023 Rule 9.4 - An element of an object shall not be initialized more than once
Supports MISRA C:2025 Rule 9.4

488
warning
enumerator symbol reuses the constant value 'integer' previously used implicitly by enumerator symbol
Two enumerators have the same value and at least one received that value implicitly. For example:

enum colors { red, blue, green = 1 };

will elicit this informational message while

enum colors { red, blue = 1, green = 1 };

will not.
Supports CERT C INT09-C - Ensure enumeration constants map to unique values
Supports MISRA C 2012 Rule 8.12 - Within an enumerator list, the value of an implicitly-speciﬁed enumeration constant shall be unique
Supports MISRA C:2023 Rule 8.12 - Within an enumerator list, the value of an implicitly-speciﬁed enumeration constant shall be unique
Supports MISRA C:2025 Rule 8.12
Supports MISRA C++:2023 Rule 11.6.3 - Within an enumerator list, the value of an implicitly-speciﬁed enumeration constant shall be unique

489
warning
attempting to modify the contents of a string literal
An assignment to an element of a string literal was seen. Doing so results in undeﬁned behavior.
Supports CERT C STR30-C - Do not attempt to modify string literals
Supports MISRA C 2012 Rule 7.4 - A string literal shall not be assigned to an object unless the object’s type is "pointer to const-qualiﬁed char"
Supports MISRA C:2023 Rule 7.4 - A string literal shall not be assigned to an object unless the object’s type is "pointer to const-qualiﬁed char"
Supports MISRA C:2025 Rule 7.4

490
warning
string
This message is issued as a result of processing a #warning preprocessor directive. string is the message provided to the directive.

491
warning
non-standard use of 'deﬁned' preprocessor operator: detail
The ISO standards restrict the use of the defined preprocessor keyword to either

defined(identifier) 
defined identifier

Additionally, the preprocessor operator may not result from the expansion of another macro. This diagnostic highlights departures from these requirements as non-portable code.
Supports AUTOSAR17 Rule M16-1-1
Supports AUTOSAR19 Rule M16-1-1
Supports MISRA C 2004 Rule 19.14 - The deﬁned preprocessor operator shall only be used in one of the two standard forms.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3
Supports MISRA C++:2008 Rule 16-1-1 - The deﬁned preprocessor operator shall only be used in one of the two standard forms.
Supports MISRA C++:2023 Rule 19.1.1 - The deﬁned preprocessor operator shall be used appropriately

492
warning
incomplete format speciﬁer 'string'
A format speciﬁer for a printf/scanf style function was started but did not contain a conversion speciﬁer. For example:

printf("%ll", 3LL);

will yield the message:

incomplete format specifier '%ll'

493
warning
position arguments in format strings start counting at 1 (not 0)
A format speciﬁer for a printf/scanf style function attempted to reference the argument at position 0 but positional arguments are indexed at 1 so this is not valid. For example:

printf("%0$d", 3);

494
warning
data argument position 'integer' exceeds the number of data arguments (integer)
A format speciﬁer for a printf/scanf style function utilizing positional arguments contained a reference to a non-existent argument, which results in undeﬁned behavior. For example:

printf("%2$d", j)

will yield the message:

data argument position '2' exceeds the number of data arguments (1)

495
warning
format string body contains NUL character
A format string for a printf/scanf style function contains a nul character in the body of the string. The receiving function will not be able to access the portion of the string after this character and its inclusion is likely a mistake. For example:

printf("%d\0%d", 1, 2);

will elicit this message.
Supports CWE-170 - Improper Null Termination
Supports CWE-464 - Addition of Data Structure Sentinel

496
warning
format string is not null terminated
The format string provided to a printf/scanf style function is not terminated with a nul character, which will cause the function to read past the end of the string causing undeﬁned behavior.
Supports CWE-170 - Improper Null Termination
Supports CWE-463 - Deletion of Data Structure Sentinel

497
warning
format string is empty
An empty format string was provided to a printf or scanf like function. Calling these functions with an empty format string is legal but suspect as there is no eﬀect to doing so.

498
warning
unbounded scanf conversion speciﬁer 'string' may result in buﬀer overﬂow
A %s or %[ conversion speciﬁer was encountered in the format string of a scanf-like function that did not contain a maximum ﬁeld width. Since the %s and %[ conversion speciﬁers read characters into the target buﬀer until either the maximum ﬁeld width is reached or a prescribed character is encountered, failing to provide a maximum ﬁeld width can easily result in buﬀer overﬂow. ’string’ contains the unbounded format speciﬁer.
Supports CERT C STR31-C - Guarantee that storage for strings has suﬃcient space for character data and the null terminator
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports CWE-120 - Buﬀer Copy without Checking Size of Input (‘Classic Buﬀer Overﬂow’)
Supports CWE-121 - Stack-based Buﬀer Overﬂow
Supports CWE-122 - Heap-based Buﬀer Overﬂow
Supports CWE-123 - Write-what-where Condition
Supports CWE-125 - Out-of-bounds Read
Supports CWE-193 - Oﬀ-by-one Error
Supports CWE-676 - Use of Potentially Dangerous Function
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

499
warning
using length modiﬁer 'string' with conversion speciﬁer 'string' is not supported by ISO C
Within the format for a printf or scanf like function, a length modiﬁer was combined with a conversion speciﬁer that is not supported by Standard C.
Supports CERT C FIO47-C - Use valid format strings
Supports CWE-134 - Use of Externally-Controlled Format String
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports CWE-686 - Function Call With Incorrect Argument Type

501
warning
negation of value of unsigned type type yields a value of unsigned type type
The unary minus operator was applied to an unsigned type. The resulting value is a positive unsigned quantity and may not be what was intended.
Supports CERT C INT02-C - Understand integer conversion rules
Supports CWE-192 - Integer Coercion Error
Supports CWE-197 - Numeric Truncation Error

502
warning
applying bitwise not to signed quantity
Unary ~ being a bit operator would more logically be applied to unsigned quantities rather than signed quantities.
Supports CERT C INT02-C - Understand integer conversion rules
Supports CERT C INT16-C - Do not make assumptions about representation of signed integers
Supports CWE-192 - Integer Coercion Error
Supports CWE-197 - Numeric Truncation Error

503
warning
boolean argument to relational
Normally a relational would not have a Boolean as argument. An example of this is a < b < c, which is technically legal but does not produce the same result as the mathematical expression, which it resembles.
Supports CERT C EXP13-C - Treat relational and equality operators as if they were nonassociative

504
warning
unusual shift operation (string)
Either the quantity being shifted or the amount by which a quantity is to be shifted was derived in an unusual way such as with a bit-wise logical operator, a negation, or with an unparenthesized expression. If the shift value is a compound expression that is not parenthesized, parenthesize it.
Supports CWE-1335 - Incorrect Bitwise Shift of Integer

505
warning
redundant left argument to comma
The left argument to the comma operator had no side eﬀects in its top-most operator and hence is redundant.
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CERT C MSC13-C - Detect and remove unused values
Supports CWE-561 - Dead Code
Supports MISRA C 2004 Rule 14.2 - All non-null statements shall either: a) have at least one side eﬀect however executed, or b) cause control ﬂow to change.
Supports MISRA C 2012 Rule 2.2 - A project shall not contain dead code
Supports MISRA C:2023 Rule 2.2 - A project shall not contain dead code
Supports MISRA C:2025 Rule 2.2

506
warning
constant value used in Boolean context (string)
A value appearing in a Boolean context, such as an operand to &&, ||, or ! or a condition of ?:, if, do, for, or while, was found to have a constant value and hence will evaluate the same way each time. This message will not be issued in contexts where a constant is required or expected, such as a static_assert condition or an array size.

Some special cases are reported using other messages:

Message 716 : while (1) or while (true)
Message 717 : do … while (0) or do … while (false)
Message 2441 : result of address-of operator used in Boolean context
Message 3416 : this pointer used in Boolean context

Supports CWE-561 - Dead Code

507
warning
explicit cast from type to type (integer bits to integer bits)
A cast was made to an integral quantity from a pointer and according to other information given or implied it would not ﬁt. For example, a cast to an unsigned int was speciﬁed and information provided by the options indicate that a pointer is larger than an int. Two integers are supplied. The ﬁrst is the size in bytes of the pointer and the second is the size in bytes of the integer.

511
warning
explicit cast from type to type (integer bits to integer bits)
A cast was made from an integral type to a pointer and the size of the quantity was too large to ﬁt into the pointer. For example if a long is cast to a pointer and if options indicate that a long is larger than a pointer, this warning would be reported.

513
warning
the option 'string' is not currently supported
The speciﬁed option is not supported in this version of PC-lint Plus but may be available in a future version.

514
warning
boolean argument to arithmetic/bitwise operator 'operator'
An argument to an arithmetic operator (+ - / * %) or a bit-wise logical operator (| & ^) was a Boolean. This can often happen by accident as in:

if( flags & 4 == 0 )

where the ==, having higher precedence than &, is done ﬁrst (to the puzzlement of the programmer).
Supports CERT C EXP46-C - Do not use a bitwise operator with a Boolean-like operand
Supports CWE-480 - Use of Incorrect Operator

517
warning
deﬁned not K&R
The defined preprocessor directive (which was not present in K&R C) was employed and the K&R preprocessor ﬂag (+fkp ) was set. Either do not set the ﬂag or do not use defined.

518
warning
expected parenthesis around type name in context expression
sizeof type is not strict C. sizeof(type) or sizeof expression are both permissible.

519
warning
explicit cast from type to type (integer bits to integer bits)
An attempt was made to cast a pointer to a pointer of unequal size. This could occur for example in a P model where pointers to functions require 4 bytes whereas pointers to data require only 2. This error message can be circumvented by ﬁrst casting the pointer to an integral quantity (int or long) before casting to a pointer.

520
warning
ﬁrst clause of for statement lacks side eﬀects
The ﬁrst expression of a for clause should either be one of the privileged operators: assignment, increment, decrement or a call to an impure function or one modifying its argument(s). See Warning 522 .
Supports MISRA C 2012 Rule 2.2 - A project shall not contain dead code
Supports MISRA C:2023 Rule 2.2 - A project shall not contain dead code
Supports MISRA C:2025 Rule 2.2

521
warning
third clause of for statement lacks side eﬀects
The third expression of a for clause should either be one of the privileged operators: assignment, increment, decrement or a call to an impure function or one modifying its argument(s). See Warning 522 .
Supports MISRA C 2012 Rule 2.2 - A project shall not contain dead code
Supports MISRA C:2023 Rule 2.2 - A project shall not contain dead code
Supports MISRA C:2025 Rule 2.2

522
warning
highest operation, string 'name', lacks side eﬀects
If a statement consists only of an expression, it should either be one of the privileged operators: assignment, increment, decrement or a call to an impure function or one modifying its argument(s). For example, if operator * is the built-in operator, the statement *p++; draws this message with string equal to operator and name equal to *. But note that p++; does not. This is because the highest operator in the former case is ’*’, which has no side eﬀects whereas p++ does. It is possible for a function to have no side-eﬀects. Such a function is called pure. See the discussion of the pure semantic in Section 9.2.1 Possible Semantics . For example:

void f() { int n = 3; n++; } 
void g() { f(); }

will trigger this message with string in the message equal to function and name equal to f.

The deﬁnition of pure and impure functions and function calls that have side eﬀects are given in the discussion of the pure semantic in Chapter 9 Semantics .
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-480 - Use of Incorrect Operator
Supports CWE-482 - Comparing instead of Assigning
Supports CWE-561 - Dead Code
Supports MISRA C 2004 Rule 14.2 - All non-null statements shall either: a) have at least one side eﬀect however executed, or b) cause control ﬂow to change.
Supports MISRA C 2012 Rule 2.2 - A project shall not contain dead code
Supports MISRA C:2023 Rule 2.2 - A project shall not contain dead code
Supports MISRA C:2025 Rule 2.2

523
warning
expression statement involving string 'name' lacks side eﬀects
This message is similar to 522 but is issued only if the entire statement lacks side eﬀects. For example:

void foo() { 
   int i = 0; 
   i++ + 1; 
}

While the operator + lacks side eﬀects, the statement doesn’t so 522 will be issued here but not 523.
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code

524
warning
implicit truncation from type to type
There is a possible loss of a fraction in converting from a ﬂoat to an integral quantity. Use of a cast will suppress this message.

525
warning
unexpected negative indentation
The current line was found to be negatively indented (i.e., not indented as much) from the indicated line. The latter corresponds to a clause introducing a control structure, and statements and other control clauses and braces within its scope are expected to have no less indentation. If tabs within your program are other than 8 blanks you should use the -t option (See Section 17.4 Indentation Checking ).
Supports CWE-483 - Incorrect Block Delimitation

526
warning
symbol symbol is not deﬁned
The named external was referenced but not deﬁned. This message is not issued for library symbols and is suppressed for unit checkout (-unit_check option). Please note that a declaration, even one bearing prototype information is not a deﬁnition. See the glossary at the beginning of this chapter. If the symbol is a library symbol, make sure that it is declared in a header ﬁle that you’re including. Also make sure that the header ﬁle is regarded by PC-lint Plus as a Library Header ﬁle. Alternatively, the symbol may be declared in a Library Module. See Section 5.1 Library Header Files and Section 5.2 Library Modules for a further discussion.

527
warning
statement is unreachable due to unconditional transfer of control by 'string' statement
A portion of the program cannot be reached. The control mechanism responsible for unconditionally diverting ﬂow away from the speciﬁed area is given by string.
Supports AUTOSAR17 Rule M0-1-1
Supports AUTOSAR19 Rule M0-1-1
Supports CERT C DCL41-C - Do not declare variables inside a switch statement before the ﬁrst case label
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code
Supports MISRA C 2004 Rule 14.1 - There shall be no unreachable code.
Supports MISRA C 2012 Rule 2.1 - A project shall not contain unreachable code
Supports MISRA C:2023 Rule 2.1 - A project shall not contain unreachable code
Supports MISRA C:2025 Rule 2.1
Supports MISRA C++:2008 Rule 0-1-1 - A project shall not contain unreachable code.
Supports MISRA C++:2023 Rule 0.0.1 - A function shall not contain unreachable statements

528
warning
static symbol symbol not referenced
The named static variable or static function was not referenced in the module after having been declared.
Supports AUTOSAR17 Rule M0-1-3
Supports AUTOSAR17 Rule M0-1-4
Supports AUTOSAR17 Rule M0-1-10
Supports AUTOSAR17 Rule A0-1-3
Supports AUTOSAR19 Rule M0-1-3
Supports AUTOSAR19 Rule M0-1-4
Supports AUTOSAR19 Rule M0-1-10
Supports AUTOSAR19 Rule A0-1-3
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code
Supports MISRA C 2012 AMD4 Rule 2.8 - A project should not contain unused object deﬁnitions
Supports MISRA C:2023 Rule 2.8 - A project should not contain unused object deﬁnitions
Supports MISRA C:2025 Rule 2.8
Supports MISRA C++:2008 Rule 0-1-3 - A project shall not contain unused variables.
Supports MISRA C++:2008 Rule 0-1-4 - A project shall not contain non-volatile POD variables having only one use.
Supports MISRA C++:2008 Rule 0-1-10 - Every deﬁned function shall be called at least once.

529
warning
local variable symbol declared in symbol not subsequently referenced
The named variable was declared but not referenced in a function.
Supports AUTOSAR17 Rule M0-1-3
Supports AUTOSAR17 Rule M0-1-4
Supports AUTOSAR19 Rule M0-1-3
Supports AUTOSAR19 Rule M0-1-4
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CERT C MSC13-C - Detect and remove unused values
Supports CWE-561 - Dead Code
Supports MISRA C 2012 AMD4 Rule 2.8 - A project should not contain unused object deﬁnitions
Supports MISRA C:2023 Rule 2.8 - A project should not contain unused object deﬁnitions
Supports MISRA C:2025 Rule 2.8
Supports MISRA C++:2008 Rule 0-1-3 - A project shall not contain unused variables.
Supports MISRA C++:2008 Rule 0-1-4 - A project shall not contain non-volatile POD variables having only one use.
Supports MISRA C++:2023 Rule 0.2.1 - Variables with limited visibility should be used at least once

530
warning
likely using an uninitialized value
An auto variable was used before it was initialized.
Supports AUTOSAR17 Rule M8-5-1
Supports AUTOSAR19 Rule A8-5-0
Supports CERT C EXP33-C - Do not read uninitialized memory
Supports CWE-457 - Use of Uninitialized Variable
Supports CWE-758 - Reliance on Undeﬁned, Unspeciﬁed, or Implementation-Deﬁned Behavior
Supports CWE-908 - Use of Uninitialized Resource
Supports MISRA C 2004 Rule 9.1 - All automatic variables shall have been assigned a value before being used.
Supports MISRA C 2012 Rule 9.1 - The value of an object with automatic storage duration shall not be read before it has been set
Supports MISRA C:2023 Rule 9.1 - The value of an object with automatic storage duration shall not be read before it has been set
Supports MISRA C:2025 Rule 9.1
Supports MISRA C++:2008 Rule 8-5-1 - All variables shall have a deﬁned value before they are used.
Supports MISRA C++:2023 Rule 11.6.2 - The value of an object must not be read before it has been set

531
warning
width of bit-ﬁeld symbol (integer bits) exceeds size of its type (integer bit(s))
The size given for a bit ﬁeld of a structure exceeds the size of an int.

533
warning
function symbol should return a value
A function declared as returning non-void either contains a return statement that is missing an expression or control may reach the end of the function without a value being returned.
Supports AUTOSAR17 Rule A8-4-2
Supports AUTOSAR19 Rule A8-4-2
Supports CERT C MSC37-C - Ensure that control never reaches the end of a non-void function
Supports CWE-758 - Reliance on Undeﬁned, Unspeciﬁed, or Implementation-Deﬁned Behavior
Supports MISRA C 2004 Rule 16.8 - All exit paths from a function with non-void return type shall have an explicit return statement with an expression.
Supports MISRA C 2012 Rule 17.4 - All exit paths from a function with non-void return type shall have an explicit return statement with an expression
Supports MISRA C:2023 Rule 17.4 - All exit paths from a function with non-void return type shall have an explicit return statement with an expression
Supports MISRA C:2025 Rule 17.4
Supports MISRA C++:2008 Rule 8-4-3 - All exit paths from a function with non-void return type shall have an explicit return statement with an expression.
Supports MISRA C++:2023 Rule 9.6.5 - A function with non-void return type shall return a value on all paths

534
warning
ignoring return value of function symbol
A function that returns a value is called just for side eﬀects as, for example, in a statement by itself or the left-hand side of a comma operator. Try: (void) function(); to call a function and ignore its return value.
Supports AUTOSAR17 Rule A0-1-2
Supports AUTOSAR19 Rule A0-1-2
Supports CERT C EXP12-C - Do not ignore values returned by functions
Supports CERT C ERR33-C - Detect and handle standard library errors
Supports CERT C POS54-C - Detect and handle POSIX library errors
Supports CWE-252 - Unchecked Return Value
Supports CWE-253 - Incorrect Check of Function Return Value
Supports CWE-391 - Unchecked Error Condition
Supports MISRA C 2004 Rule 16.10 - If a function returns error information, then that error information shall be tested.
Supports MISRA C 2012 Dir 4.7 - If a function returns error information, then that error information shall be tested
Supports MISRA C 2012 Rule 17.7 - The value returned by a function having non-void return type shall be used
Supports MISRA C:2023 Dir 4.7 - If a function returns error information, then that error information shall be tested
Supports MISRA C:2023 Rule 17.7 - The value returned by a function having non-void return type shall be used
Supports MISRA C:2025 Dir 4.7
Supports MISRA C:2025 Rule 17.7
Supports MISRA C++:2008 Rule 0-1-7 - The value returned by a function having a non-void return type that is not an overloaded operator shall always be used.
Supports MISRA C++:2008 Rule 0-3-2 - If a function generates error information, then that error information shall be tested.
Supports MISRA C++:2023 Rule 0.1.2 - The value returned by a function shall be used

537
warning
repeated include ﬁle 'ﬁle'
The ﬁle whose inclusion within a module is being requested has already been included in this compilation. The ﬁle is processed normally even if the message is given. If it is your standard practice to repeat included ﬁles then simply suppress this message.

539
warning
unexpected positive indentation
The current line was found to be positively indented from a clause that did not control the line in question. For example:

if( n > 0 ) 
   x = 3; 
   y = 4;

will result in this warning being issued for y = 4;.
Supports CWE-483 - Incorrect Block Delimitation

540
warning
initializer-string for char array is too long, array size is integer but initializer has size integer (including the null terminating character)
A string initializer required more space than what was allocated.

542
warning
excessive size for bit ﬁeld
An attempt was made to assign a value into a bit ﬁeld that appears to be too small.

You may get this message unexpectedly if the base of the bit ﬁeld is an int. For example:

struct { int b : 1 } s; 
s.b = 1; /* Warning -- requires 0 or -1 */

The solution in this case is to use ’unsigned’ rather than ’int’ in the declaration of b.

544
warning
string directive not followed by EOL
The preprocessor directive #endif should be followed by an end-of-line. Some compilers speciﬁcally allow commentary to follow the #endif. If you are following that convention simply turn this error message oﬀ.
Supports AUTOSAR17 Rule M16-0-8
Supports AUTOSAR19 Rule M16-0-8
Supports MISRA C 2004 Rule 19.16 - Preprocessing directives shall be syntactically meaningful even when excluded by the preprocessor.
Supports MISRA C 2012 Rule 20.3 - The #include directive shall be followed by either a <ﬁlename> or "ﬁlename" sequence
Supports MISRA C 2012 Rule 20.13 - A line whose ﬁrst token is # shall be a valid preprocessing directive
Supports MISRA C:2023 Rule 20.3 - The #include directive shall be followed by either a <ﬁlename> or "ﬁlename" sequence
Supports MISRA C:2023 Rule 20.13 - A line whose ﬁrst token is # shall be a valid preprocessing directive
Supports MISRA C:2025 Rule 20.3
Supports MISRA C:2025 Rule 20.13
Supports MISRA C++:2008 Rule 16-0-8 - If the # token appears as the ﬁrst token on a line, then it shall be immediately followed by a preprocessing token.
Supports MISRA C++:2023 Rule 19.0.1 - A line whose ﬁrst token is # shall be a valid preprocessing directive

545
warning
taking address of array
An attempt was made to take the address of an array name. At one time such an expression was oﬃcially illegal (K&R C [?]), was not consistently implemented, and was, therefore, suspect. However, the expression is legal in ANSI/ ISO C and designates a pointer to an array. For example, given

int a[10]; 
int (*p) [10];

Then a and &a, as pointers, both represent the same bit pattern, but whereas a is a pointer to int, &a is a pointer to an array of 10 integers. Of the two only &a may be assigned to p without complaint. If you are using the & operator in this way, we recommend that you disable this message.

546
warning
explicitly taking address of function
An attempt was made to take the address of a function name. Since names of functions by themselves are promoted to address, the use of the & is redundant and could be erroneous.

547
warning
redeﬁnition of macro name conﬂicts with previous deﬁnition
The indicated symbol had previously been deﬁned (via #define) to some other value. If a macro is deﬁned inconsistently across modules, then message 767 will be reported.
Supports MISRA C 2012 Rule 5.4 - Macro identiﬁers shall be distinct
Supports MISRA C:2023 Rule 5.4 - Macro identiﬁers shall be distinct
Supports MISRA C:2025 Rule 5.4

548
warning
if statement has no body or else
A construct of the form if(e); was found, and it was not followed by an else. This is almost certainly an unwanted semi-colon as it inhibits the if from having any eﬀect.

549
warning
explicit cast from type to type
A cast was made from a pointer to some enumerated type or from an enumerated type to a pointer. This is probably an error. Check your code and if this is not an error, then cast the item to an intermediate form (such as an int or a long) before making the ﬁnal cast.

550
warning
local variable symbol declared in symbol not subsequently accessed
A variable (local to some function) was not accessed. This means that the value of a variable was never used. Perhaps the variable was assigned a value but was never used. Note that a variable’s value is not considered accessed by autoincrementing or autodecrementing unless the autoincrement/decrement appears within a larger expression, which uses the resulting value. The same applies to a construct of the form: var += expression. If an address of a variable is taken, its value is assumed to be accessed. However, casting that address to a non-pointer causes Lint to forget this sense of "accessed-ness." An array, struct or union is considered accessed if any portion thereof is accessed.
Supports AUTOSAR17 Rule M0-1-4
Supports AUTOSAR19 Rule M0-1-4
Supports MISRA C++:2008 Rule 0-1-4 - A project shall not contain non-volatile POD variables having only one use.

551
warning
static variable symbol not accessed
A variable (declared static at the module level) was not accessed though the variable was referenced. See the explanation under message 550 (above) for a description of "access".
Supports AUTOSAR17 Rule M0-1-4
Supports AUTOSAR19 Rule M0-1-4
Supports MISRA C++:2008 Rule 0-1-4 - A project shall not contain non-volatile POD variables having only one use.

552
warning
external variable symbol not accessed
An external variable was not accessed though the variable was referenced. See the explanation under message 550 above for a description of "access". This message is not issued for library symbols and is suppressed for unit checkout (-unit_check option).
Supports AUTOSAR17 Rule M0-1-4
Supports AUTOSAR19 Rule M0-1-4
Supports MISRA C++:2008 Rule 0-1-4 - A project shall not contain non-volatile POD variables having only one use.

553
warning
undeﬁned preprocessor variable name, assumed 0
The indicated variable had not previously been deﬁned within a #define statement and yet it is being used in a preprocessor condition of the form #if or #elif. Conventionally all variables in preprocessor expressions should be pre-deﬁned. The value of the variable is assumed to be 0.
Supports AUTOSAR17 Rule M16-0-7
Supports AUTOSAR19 Rule M16-0-7
Supports MISRA C 2004 Rule 19.11 - All macro identiﬁers in preprocessor directives shall be deﬁned before use, except in #ifdef and #ifndef preprocessor directives and the deﬁned() operator.
Supports MISRA C 2012 Rule 20.9 - All identiﬁers used in the controlling expression of #if or #elif preprocessing directives shall be #deﬁne’d before evaluation
Supports MISRA C:2023 Rule 20.9 - All identiﬁers used in the controlling expression of #if or #elif preprocessing directives shall be #deﬁne’d before evaluation
Supports MISRA C:2025 Rule 20.9
Supports MISRA C++:2008 Rule 16-0-7 - Undeﬁned macro identiﬁers shall not be used in #if or #elif preprocessor directives, except as operands to the deﬁned operator.
Supports MISRA C++:2023 Rule 19.1.3 - All identiﬁers used in the controlling expression of #if or #elif preprocessing directives shall be deﬁned prior to evaluation

555
warning
#elif not K&R
The #elif directive was used and the K&R preprocessor ﬂag (+fkp ) was set. Either do not set the ﬂag or do not use #elif.

557
warning
invalid conversion speciﬁer 'string'
The format string supplied to a printf/scanf style function was not recognized. It is neither a standard format nor a recognized common extension (see message 816 ).
Supports CERT C FIO47-C - Use valid format strings
Supports CWE-134 - Use of Externally-Controlled Format String
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports CWE-686 - Function Call With Incorrect Argument Type
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

558
warning
too few data arguments for format string (integer missing)
The number of arguments supplied to a printf/scanf style function was less than the number expected. The number of missing arguments is given by integer. See also message 719 .
Supports CERT C DCL10-C - Maintain the contract between the writer and caller of variadic functions
Supports CERT C FIO47-C - Use valid format strings
Supports CWE-134 - Use of Externally-Controlled Format String
Supports CWE-628 - Function Call with Incorrectly Speciﬁed Arguments
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports CWE-686 - Function Call With Incorrect Argument Type
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

559
warning
format 'string' speciﬁes type type which is inconsistent with argument no. integer of string type
The argument corresponding to a conversion speciﬁer in a printf/scanf style function was not of the correct type. The format, expected argument type, argument number, and the type of the data argument provided are reported. Argument counts begin at 1 and include ﬁle, string, and data arguments. For example:

extern char * buffer; 
sprintf(buffer, "%f", 371);

will result in the message:

format '\%f' specifies type 'double' which is inconsistent with 
argument no. 3 of type 'int'

For conﬂicting integer types that diﬀer only in signedness (e.g. int vs. unsigned int) or exact type (e.g. int vs. long when both are the same size) 705 is given instead. For conﬂicting pointer to integer types that diﬀer only in the signedness or exact type of the pointee, 706 is given.
Supports CERT C DCL11-C - Understand the type issues associated with variadic functions
Supports CERT C INT00-C - Understand the data model used by your implementation(s)
Supports CERT C FIO47-C - Use valid format strings
Supports CWE-134 - Use of Externally-Controlled Format String
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports CWE-686 - Function Call With Incorrect Argument Type
Supports CWE-843 - Access of Resource Using Incompatible Type (‘Type Confusion’)

563
warning
label name not referenced
name appeared as a label but there was no statement that referenced this label.
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code
Supports MISRA C 2012 Rule 2.6 - A function should not contain unused label declarations
Supports MISRA C:2023 Rule 2.6 - A function should not contain unused label declarations
Supports MISRA C:2025 Rule 2.6

564
warning
variable symbol depends on order of evaluation
The named variable was both modiﬁed and accessed in the same expression in such a way that the result depends on whether the order of evaluation is left-to-right or right-to-left. One such example is: n + n++ since there is no guarantee that the ﬁrst access to n occurs before the increment of n. This message is also triggered by the potential modiﬁcation of an object by a call to a function whose corresponding parameter is a non-const reference or a non-const pointer. Volatile variables are also checked for repeated use in an expression.
Supports AUTOSAR17 Rule A5-0-1
Supports AUTOSAR19 Rule A5-0-1
Supports CERT C EXP10-C - Do not depend on the order of evaluation of subexpressions or the order in which side eﬀects take place
Supports CERT C EXP30-C - Do not depend on the order of evaluation for side eﬀects
Supports CWE-758 - Reliance on Undeﬁned, Unspeciﬁed, or Implementation-Deﬁned Behavior
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2004 Rule 12.2 - The value of an expression shall be the same under any order of evaluation that the standard permits.
Supports MISRA C 2012 Rule 13.2 - The value of an expression and its persistent side eﬀects shall be the same under all permitted evaluation orders
Supports MISRA C:2023 Rule 13.2 - The value of an expression and its persistent side eﬀects shall be the same under all permitted evaluation orders
Supports MISRA C:2025 Rule 13.2
Supports MISRA C++:2008 Rule 5-0-1 - The value of an expression shall be the same under any order of evaluation that the standard permits.
Supports MISRA C++:2023 Rule 4.6.1 - Operations on a memory location shall be sequenced appropriately

565
warning
declaration of tag type will not be visible outside of this function
The named tag appeared in a function prototype in a C module and does not correspond to a previously seen declaration in an outer (ﬁle-level) scope. Move the tag declaration before the function if the intention is for it to be visible outside the function.

566
warning
inconsistent or redundant length modiﬁer/ﬂag 'string' used with 'string' conversion speciﬁer
This message is given for format speciﬁers within formats for the printf/scanf family of functions. The indicated length modiﬁer or ﬂag character found in a format speciﬁer either has no eﬀect or is not allowed to be combined with the provided conversion speciﬁer. For example:

printf("%+u", 123);

will yield the message:

inconsistent or redundant flag '+' used with 'u' conversion specifier

because the + ﬂag is valid only with signed conversions, its use with other conversions results in undeﬁned behavior.
Supports CERT C FIO47-C - Use valid format strings
Supports CWE-134 - Use of Externally-Controlled Format String
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports CWE-686 - Function Call With Incorrect Argument Type
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

567
warning
expected minimum ﬁeld width for ﬂag 'string'
This message is given for format speciﬁers within formats for the printf/scanf family of functions. A numeric ﬁeld or asterisk was expected at a particular point in the scanning of the format. For example: %-d requests left justiﬁcation of a decimal integer within a format ﬁeld. But since no ﬁeld width is given, the request is meaningless.

568
warning
nonnegative quantity is never less than zero
Comparisons of the form:

u >= 0     0 <= u 
u <  0     0 >  u

are suspicious if u is an unsigned quantity or a quantity judged to be never less then 0. See also message 775 .

569
warning
loss of information (context) in implicit conversion from type integer (integer bits) to type (integer bits)
An assignment (or implied assignment, see context) was made from a constant to an integral variable that is not large enough to hold the constant. Examples include placing a hex constant whose bit requirement is such as to require an unsigned int into a variable typed as int. The number of bits given does not count the sign bit.
Supports CERT C INT02-C - Understand integer conversion rules
Supports CWE-192 - Integer Coercion Error
Supports CWE-197 - Numeric Truncation Error

570
warning
negative type integer loses sign during implicit conversion (context) to type
An assignment (or implied assignment, see context) is being made from a negative constant into an unsigned quantity. Casting the constant to unsigned will remove the diagnostic but is this what you want? If you are assigning all ones to an unsigned, remember that ~0 represents all ones and is more portable than -1.
Supports CERT C INT02-C - Understand integer conversion rules
Supports CWE-192 - Integer Coercion Error
Supports CWE-197 - Numeric Truncation Error

571
warning
cast from type to type results in sign extension
Usually this warning is issued for casts of the form:

(unsigned) ch

where ch is declared as char and char is signed. Although the cast may appear to prevent sign extension of ch, it does not. Following the normal conversion rules of C, if ch is negative then it cannot be represented in an unsigned type and so a quantity of 2**n is added to the signed quantity where n is the number of bits in the destination. If 2**m were added, where m is the number of bits in the source, i.e. ch, then the sign extension would not occur. To suppress sign extension you may use:

(unsigned char) ch

Otherwise, if sign extension is what you want and you just want to suppress the warning in this instance you may use:

(unsigned) (int) ch

Although these examples have been given in terms of casting a char, this message will also be given whenever this cast is made upon a signed quantity whose size is less than the casted type. Examples include signed bit ﬁelds, expressions involving char, and expressions involving short when this type is smaller than int or a direct cast of an int to an unsigned long (if int is smaller than long). This message is not issued for constants or for expressions involving bit operations.
Supports CERT C STR34-C - Cast characters to unsigned char before converting to larger integer sizes
Supports CWE-704 - Incorrect Type Conversion or Cast

572
warning
excessive shift value (precision integer shifted right by integer)
A quantity is being shifted to the right whose precision is equal to or smaller than the shifted value. For example,

ch >> 10

will elicit this message if ch is typed char and where char is less than 10 bits wide (the usual case). To suppress the message in this case you may cast the shifted quantity to a type whose length is at least the length of the shift value.

The precision of a constant (including enumeration constants) is determined from the number of bits required in its binary representation. The precision does not change with a cast so that (unsigned) 1 >> 3 still yields the message. But normally the only way an expression such as 1 >> 3 can legitimately occur is via a macro. In this case use -emacro .
Supports CWE-1335 - Incorrect Bitwise Shift of Integer

573
warning
signed-unsigned mix with divide
one of the operands to / or % was signed and the other unsigned; moreover the signed quantity could be negative. For example:

u / n

where u is unsigned and n is signed will elicit this message whereas:

u / 4

will not, even though 4 is nominally an int. It is not a good idea to mix unsigned quantities with signed quantities in any case (a 737 will also be issued) but, with division, a negative value can create havoc. For example, the innocent looking:

n = n / u

will, if n is -2 and u is 2, not assign -1 to n but will assign some very large value.

To resolve this problem, either cast the integer to unsigned if you know it can never be less than zero or cast the unsigned to an integer if you know it can never exceed the maximum integer.
Supports CERT C INT02-C - Understand integer conversion rules
Supports CWE-192 - Integer Coercion Error
Supports CWE-197 - Numeric Truncation Error

574
warning
signed-unsigned mix with relational
The four relational operators are:

>  >=  <  <=

One of the operands to a relational operator was signed and the other unsigned; also, the signed quantity could be negative. For example:

if( u > n) ...

where u is unsigned and n is signed will elicit this message whereas:

if( u > 12 ) ...

will not (even though 12 is oﬃcially an int it is obvious that it is not negative). It is not a good idea to mix unsigned quantities with signed quantities in any case (a 737 will also be issued) but, with the four relationals, a negative value can produce obscure results. For example, if the conditional:

if( n < 0 ) ...

is true then the similar appearing:

u = 0; 
if( n < u ) ...

is false because the promotion to unsigned makes n very large.

To resolve this problem, either cast the integer to unsigned if you know it can never be less than zero or cast the unsigned to an int if you know it can never exceed the maximum int.
Supports CERT C INT02-C - Understand integer conversion rules
Supports CWE-192 - Integer Coercion Error
Supports CWE-197 - Numeric Truncation Error

575
warning
enumeration constant exceeds range for integers
For many compilers the value of an enumeration constant is limited to those values that can ﬁt within a signed or unsigned int.

576
warning
excess elements in string initializer
In a brace-enclosed initializer, there are more items than there are elements of the aggregate, which will result in undeﬁned behavior as this is a constraint violation in C. For example:

int array[3] = {1, 2, 3, 4};

In C++, an error is emitted instead.
Supports CERT C ARR02-C - Explicitly specify array bounds, even if implicitly deﬁned by an initializer
Supports CWE-665 - Improper Initialization
Supports MISRA C 2004 Rule 9.2 - Braces shall be used to indicate and match the structure in the non-zero initialisation of arrays and structures.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

578
warning
declaration of symbol hides string
A local symbol has the identical name as a variable or ﬁeld speciﬁed by detail. This could be dangerous. Was this deliberate? It is usually best to rename the local symbol.
Supports AUTOSAR17 Rule A2-11-1
Supports AUTOSAR19 Rule A2-10-1
Supports CERT C DCL01-C - Do not reuse variable names in subscopes
Supports MISRA C 2004 Rule 5.2 - Identiﬁers in an inner scope shall not use the same name as an identiﬁer in an outer scope, and therefore hide that identiﬁer.
Supports MISRA C 2012 Rule 5.3 - An identiﬁer declared in an inner scope shall not hide an identiﬁer declared in an outer scope
Supports MISRA C:2023 Rule 5.3 - An identiﬁer declared in an inner scope shall not hide an identiﬁer declared in an outer scope
Supports MISRA C:2025 Rule 5.3
Supports MISRA C++:2008 Rule 2-10-2 - Identiﬁers declared in an inner scope shall not hide an identiﬁer declared in an outer scope.
Supports MISRA C++:2023 Rule 6.4.1 - A variable declared in an inner scope shall not hide a variable declared in an outer scope

579
warning
parameter preceding ellipsis cannot be 'string'
When an ellipsis is used, the type of the parameter immediately preceding the ellipsis should not be a type that would undergo a default promotion such as char, short or float, a reference type, or a parameter declared with the register keyword. The C and C++ standards explicitly state that attempting to extract variable arguments from a call to such a function results in undeﬁned behavior. The string parameter is one of: a promotable integer type, a promotable floating point type, a reference type, or declared as register.

580
warning
redeclaration of function symbol causes loss of prototype
A declaration of a function within a block hides a declaration in an outer scope in such a way that the inner declaration has no prototype and the outer declaration does. A common misconception is that the resulting declaration is a composite of both declarations but this is only the case when the declarations are in the same scope not within nested scopes. If you do not care about prototypes you may suppress this message. You will still receive other type-diﬀerence warnings.

583
warning
comparing type 'type' with EOF
This message is issued when some form of character is compared against the EOF macro. EOF is normally deﬁned to be -1. For example:

while( (ch = getchar()) != EOF ) ...

If ch is deﬁned to be an int all is well. If however it is deﬁned to be some form of char, then trouble might ensue. If ch is an unsigned char then it can never equal EOF. If ch is a signed char then you could get a premature termination because some data character happened to be all ones.

Note that getchar returns an int. The reason it returns an int and not a char is because it must be capable of returning 257 diﬀerent values (256 diﬀerent characters plus EOF, assuming an 8-bit character). Once this value is assigned to a char only 256 values are then possible – a clear loss of information.

584
warning
trigraph sequence (??character) detected
This message is issued whenever a trigraph sequence is detected and the trigraph processing has been turned oﬀ (with a -ftg ). If this is within a string (or character) constant then the trigraph nature of the sequence is ignored. That is, three characters are produced rather than just one. This is useful if your compiler does not process trigraph sequences and you want linting to mirror compilation. Outside of a string we issue this warning but we do translate the sequence since it cannot make syntactic sense in its raw state.
Supports AUTOSAR17 Rule A2-5-1
Supports AUTOSAR19 Rule A2-5-1
Supports CERT C PRE07-C - Avoid using repeated question marks
Supports MISRA C 2004 Rule 4.2 - Trigraphs shall not be used.
Supports MISRA C 2012 Rule 4.2 - Trigraphs should not be used
Supports MISRA C:2023 Rule 4.2 - Trigraphs should not be used
Supports MISRA C:2025 Rule 4.2
Supports MISRA C++:2008 Rule 2-3-1 - Trigraphs shall not be used.
Supports MISRA C++:2023 Rule 5.0.1 - Trigraph-like sequences should not be used

585
warning
the sequence (??character) is not a valid trigraph sequence
This warning is issued whenever a pair of ’?’ characters is seen within a string (or character) constant but that pair is not followed by a character, which would make the triple a valid Trigraph sequence. Did the programmer intend this to be a Trigraph sequence and merely err? Even if no Trigraph were intended it can easily be mistaken by the reader of the code to be a Trigraph. Moreover, what assurances do we have that in the future the invalid Trigraph might not become a valid Trigraph and change the meaning of the string? To protect yourself from such an event you may place a backslash between the ’?’ characters. Alternatively you may use concatenation of string constants. For example:

pattern = "(???) ???-????";         // warning 585 
pattern = "(?\?\?) ?\?\?-?\?\?\?";   // no warning 
#define Q "?" 
pattern="(" Q Q Q ") " Q Q Q "-" Q Q Q Q;       //no warning

586
warning
string 'name' is deprecated. string
The name has been deprecated by some use of the deprecate option. See -deprecate . The ﬁrst string is one of the allowed categories of deprecation. The trailing string is part of the deprecate option and should explain why the facility has been deprecated.
Supports AUTOSAR17 Rule A0-4-2
Supports AUTOSAR17 Rule A1-1-1
Supports AUTOSAR17 Rule A2-14-3
Supports AUTOSAR17 Rule A3-9-1
Supports AUTOSAR17 Rule A5-2-1
Supports AUTOSAR17 Rule A5-2-4
Supports AUTOSAR17 Rule A7-1-4
Supports AUTOSAR17 Rule A7-4-1
Supports AUTOSAR17 Rule A15-5-2
Supports AUTOSAR17 Rule A16-0-1
Supports AUTOSAR17 Rule A16-6-1
Supports AUTOSAR17 Rule A16-7-1
Supports AUTOSAR17 Rule M17-0-5
Supports AUTOSAR17 Rule A18-0-2
Supports AUTOSAR17 Rule M18-0-3
Supports AUTOSAR17 Rule M18-0-4
Supports AUTOSAR17 Rule M18-0-5
Supports AUTOSAR17 Rule A18-0-3
Supports AUTOSAR17 Rule A18-1-2
Supports AUTOSAR17 Rule A18-1-3
Supports AUTOSAR17 Rule M18-2-1
Supports AUTOSAR17 Rule A18-5-1
Supports AUTOSAR17 Rule M18-7-1
Supports AUTOSAR17 Rule A18-9-1
Supports AUTOSAR17 Rule M19-3-1
Supports AUTOSAR17 Rule M27-0-1
Supports AUTOSAR19 Rule A0-4-2
Supports AUTOSAR19 Rule A1-1-1
Supports AUTOSAR19 Rule A2-11-1
Supports AUTOSAR19 Rule A2-13-3
Supports AUTOSAR19 Rule A3-9-1
Supports AUTOSAR19 Rule A5-2-1
Supports AUTOSAR19 Rule A5-2-4
Supports AUTOSAR19 Rule A7-1-4
Supports AUTOSAR19 Rule A7-4-1
Supports AUTOSAR19 Rule A15-5-2
Supports AUTOSAR19 Rule A16-0-1
Supports AUTOSAR19 Rule A16-6-1
Supports AUTOSAR19 Rule A16-7-1
Supports AUTOSAR19 Rule M17-0-5
Supports AUTOSAR19 Rule A18-0-2
Supports AUTOSAR19 Rule M18-0-3
Supports AUTOSAR19 Rule M18-0-4
Supports AUTOSAR19 Rule M18-0-5
Supports AUTOSAR19 Rule A18-0-3
Supports AUTOSAR19 Rule A18-1-2
Supports AUTOSAR19 Rule A18-1-3
Supports AUTOSAR19 Rule M18-2-1
Supports AUTOSAR19 Rule A18-5-1
Supports AUTOSAR19 Rule M18-7-1
Supports AUTOSAR19 Rule A18-9-1
Supports AUTOSAR19 Rule M19-3-1
Supports AUTOSAR19 Rule A26-5-1
Supports AUTOSAR19 Rule M27-0-1
Supports CERT C EXP43-C - Avoid undeﬁned behavior when using restrict-qualiﬁed pointers
Supports CERT C INT05-C - Do not use input functions to convert character data if they cannot handle all possible inputs
Supports CERT C STR07-C - Use the bounds-checking interfaces for string manipulation
Supports CERT C ENV33-C - Do not call system()
Supports CERT C SIG00-C - Mask signals handled by noninterruptible signal handlers
Supports CERT C SIG01-C - Understand implementation-speciﬁc details regarding signal handler persistence
Supports CERT C SIG02-C - Avoid using signals to implement normal functionality
Supports CERT C ERR04-C - Choose an appropriate termination strategy
Supports CERT C ERR06-C - Understand the termination behavior of assert() and abort()
Supports CERT C ERR07-C - Prefer functions that support error checking over equivalent functions that don’t
Supports CERT C ERR34-C - Detect errors when converting a string to a number
Supports CERT C MSC06-C - Beware of compiler optimizations
Supports CERT C MSC18-C - Be careful while handling sensitive data, such as passwords, in program code
Supports CERT C MSC24-C - Do not use deprecated or obsolescent functions
Supports CERT C MSC30-C - Do not use the rand() function for generating pseudorandom numbers
Supports CERT C MSC33-C - Do not pass invalid data to the asctime() function
Supports CERT C WIN00-C - Be speciﬁc when dynamically loading libraries
Supports CERT C WIN01-C - Do not forcibly terminate execution
Supports CERT C WIN02-C - Restrict privileges when spawning child processes
Supports CERT C CON33-C - Avoid race conditions when using library functions
Supports CERT C CON37-C - Do not call signal() in a multithreaded program
Supports CERT C POS04-C - Avoid using PTHREAD_MUTEX_NORMAL type mutex locks
Supports CERT C POS33-C - Do not use vfork()
Supports CERT C POS44-C - Do not use signals to terminate threads
Supports CERT C POS47-C - Do not use threads that can be canceled asynchronously
Supports CWE-14 - Compiler Removal of Code to Clear Buﬀers
Supports CWE-20 - Improper Input Validation
Supports CWE-78 - Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)
Supports CWE-88 - Improper Neutralization of Argument Delimiters in a Command (‘Argument Injection’)
Supports CWE-192 - Integer Coercion Error
Supports CWE-197 - Numeric Truncation Error
Supports CWE-242 - Use of Inherently Dangerous Function
Supports CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
Supports CWE-330 - Use of Insuﬃciently Random Values
Supports CWE-338 - Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
Supports CWE-377 - Insecure Temporary File
Supports CWE-391 - Unchecked Error Condition
Supports CWE-403 - Exposure of File Descriptor to Unintended Control Sphere (‘File Descriptor Leak’)
Supports CWE-462 - Duplicate Key in Associative List (Alist)
Supports CWE-477 - Use of Obsolete Function
Supports CWE-558 - Use of getlogin() in Multithreaded Application
Supports CWE-662 - Improper Synchronization
Supports CWE-676 - Use of Potentially Dangerous Function
Supports CWE-705 - Incorrect Control Flow Scoping
Supports CWE-758 - Reliance on Undeﬁned, Unspeciﬁed, or Implementation-Deﬁned Behavior
Supports CWE-1341 - Multiple Releases of Same Resource or Handle
Supports MISRA C 2004 Rule 20.4 - Dynamic heap memory allocation shall not be used.
Supports MISRA C 2004 Rule 20.5 - The error indicator errno shall not be used.
Supports MISRA C 2004 Rule 20.6 - The macro oﬀsetof, in library <stddef.h>, shall not be used.
Supports MISRA C 2004 Rule 20.7 - The setjmp macro and the longjmp function shall not be used.
Supports MISRA C 2004 Rule 20.8 - The signal handling facilities of <signal.h> shall not be used.
Supports MISRA C 2004 Rule 20.9 - The input/output library <stdio.h> shall not be used in production code.
Supports MISRA C 2004 Rule 20.10 - The library functions atof, atoi and atol from library <stdlib.h> shall not be used.
Supports MISRA C 2004 Rule 20.11 - The library functions abort, exit, getenv and system from library <stdlib.h> shall not be used.
Supports MISRA C 2004 Rule 20.12 - The time handling functions of library <time.h> shall not be used.
Supports MISRA C 2012 Dir 4.12 - Dynamic memory allocation shall not be used
Supports MISRA C 2012 Rule 8.14 - The restrict type qualiﬁer shall not be used
Supports MISRA C 2012 Rule 17.1 - The features of <stdarg.h> shall not be used
Supports MISRA C 2012 Rule 21.3 - The memory allocation and deallocation functions of <stdlib.h> shall not be used
Supports MISRA C 2012 Rule 21.4 - The standard header ﬁle <setjmp.h> shall not be used
Supports MISRA C 2012 Rule 21.5 - The standard header ﬁle <signal.h> shall not be used
Supports MISRA C 2012 Rule 21.6 - The Standard Library input/output functions shall not be used
Supports MISRA C 2012 Rule 21.7 - The atof, atoi, atol and atoll functions of <stdlib.h> shall not be used
Supports MISRA C 2012 Rule 21.8 - The library functions abort, exit, getenv and system of <stdlib.h> shall not be used
Supports MISRA C 2012 Rule 21.9 - The library functions bsearch and qsort of <stdlib.h> shall not be used
Supports MISRA C 2012 Rule 21.10 - The Standard Library time and date functions shall not be used
Supports MISRA C 2012 Rule 21.12 - The standard header ﬁle <fenv.h> shall not be used
Supports MISRA C 2012 AMD2 Rule 1.4 - Emergent language features shall not be used
Supports MISRA C 2012 AMD2 Rule 21.3 - The memory allocation and deallocation functions of <stdlib.h> shall not be used
Supports MISRA C 2012 AMD2 Rule 21.8 - The Standard Library termination functions of <stdlib.h> shall not be used
Supports MISRA C 2012 AMD2 Rule 21.21 - The Standard Library function system of <stdlib.h> shall not be used
Supports MISRA C 2012 AMD3 Rule 21.24 - The random number generator functions of <stdlib.h> shall not be used
Supports MISRA C 2012 AMD4 Dir 5.3 - There shall be no dynamic thread creation
Supports MISRA C:2023 Dir 4.12 - Dynamic memory allocation shall not be used
Supports MISRA C:2023 Dir 5.3 - There shall be no dynamic thread creation
Supports MISRA C:2023 Rule 1.4 - Emergent language features shall not be used
Supports MISRA C:2023 Rule 8.14 - The restrict type qualiﬁer shall not be used
Supports MISRA C:2023 Rule 17.1 - The standard header ﬁle <stdarg.h> shall not be used
Supports MISRA C:2023 Rule 21.3 - The memory allocation and deallocation functions of <stdlib.h> shall not be used
Supports MISRA C:2023 Rule 21.4 - The standard header ﬁle <setjmp.h> shall not be used
Supports MISRA C:2023 Rule 21.5 - The standard header ﬁle <signal.h> shall not be used
Supports MISRA C:2023 Rule 21.6 - The Standard Library input/output functions shall not be used
Supports MISRA C:2023 Rule 21.7 - The Standard Library functions atof, atoi, atol and atoll of <stdlib.h> shall not be used
Supports MISRA C:2023 Rule 21.8 - The Standard Library termination functions of <stdlib.h> shall not be used
Supports MISRA C:2023 Rule 21.9 - The Standard Library functions bsearch and qsort of <stdlib.h> shall not be used
Supports MISRA C:2023 Rule 21.10 - The Standard Library time and date functions shall not be used
Supports MISRA C:2023 Rule 21.12 - The standard header ﬁle <fenv.h> shall not be used
Supports MISRA C:2023 Rule 21.21 - The Standard Library function system of <stdlib.h> shall not be used
Supports MISRA C:2023 Rule 21.24 - The random number generator functions of <stdlib.h> shall not be used
Supports MISRA C:2025 Dir 4.12
Supports MISRA C:2025 Dir 5.3
Supports MISRA C:2025 Rule 1.4
Supports MISRA C:2025 Rule 8.14
Supports MISRA C:2025 Rule 17.1
Supports MISRA C:2025 Rule 21.3
Supports MISRA C:2025 Rule 21.4
Supports MISRA C:2025 Rule 21.5
Supports MISRA C:2025 Rule 21.6
Supports MISRA C:2025 Rule 21.7
Supports MISRA C:2025 Rule 21.8
Supports MISRA C:2025 Rule 21.9
Supports MISRA C:2025 Rule 21.10
Supports MISRA C:2025 Rule 21.12
Supports MISRA C:2025 Rule 21.21
Supports MISRA C:2025 Rule 21.24
Supports MISRA C++:2008 Rule 17-0-5 - The setjmp macro and the longjmp function shall not be used.
Supports MISRA C++:2008 Rule 18-0-2 - The library functions atof, atoi and atol from library <cstdlib> shall not be used.
Supports MISRA C++:2008 Rule 18-0-3 - The library functions abort, exit, getenv and system from library <cstdlib> shall not be used.
Supports MISRA C++:2008 Rule 18-0-5 - The unbounded functions of library <cstring> shall not be used.
Supports MISRA C++:2008 Rule 18-2-1 - The macro oﬀsetof shall not be used.
Supports MISRA C++:2008 Rule 18-4-1 - Dynamic heap memory allocation shall not be used.
Supports MISRA C++:2008 Rule 19-3-1 - The error indicator errno shall not be used.
Supports MISRA C++:2023 Rule 4.1.2 - Deprecated features should not be used
Supports MISRA C++:2023 Rule 7.11.1 - nullptr shall be the only form of the null-pointer-constant
Supports MISRA C++:2023 Rule 12.3.1 - The union keyword shall not be used
Supports MISRA C++:2023 Rule 18.5.2 - Program-terminating functions should not be used
Supports MISRA C++:2023 Rule 19.6.1 - The #pragma directive and the _Pragma operator should not be used
Supports MISRA C++:2023 Rule 21.2.1 - The library functions atof, atoi, atol and atoll from <cstdlib> shall not be used
Supports MISRA C++:2023 Rule 21.2.2 - The string handling functions from <cstring>, <cstdlib>, <cwchar> and <cinttypes> shall not be used
Supports MISRA C++:2023 Rule 21.2.3 - The library function system from <cstdlib> shall not be used
Supports MISRA C++:2023 Rule 21.2.4 - The macro oﬀsetof shall not be used
Supports MISRA C++:2023 Rule 21.6.1 - Dynamic memory should not be used
Supports MISRA C++:2023 Rule 21.6.2 - Dynamic memory shall be managed automatically
Supports MISRA C++:2023 Rule 21.10.1 - The features of <cstdarg> shall not be used
Supports MISRA C++:2023 Rule 21.10.2 - The standard header ﬁle <csetjmp> shall not be used
Supports MISRA C++:2023 Rule 21.10.3 - The facilities provided by the standard header ﬁle <csignal> shall not be used
Supports MISRA C++:2023 Rule 24.5.1 - The character handling functions from <cctype> and <cwctype> shall not be used
Supports MISRA C++:2023 Rule 24.5.2 - The C++ Standard Library functions memcpy, memmove and memcmp from <cstring> shall not be used
Supports MISRA C++:2023 Rule 25.5.1 - The setlocale and std::locale::global functions shall not be called
Supports MISRA C++:2023 Rule 26.3.1 - std::vector should not be specialized with bool
Supports MISRA C++:2023 Rule 30.0.1 - The C Library input/output functions shall not be used

587
warning
predicate 'string' can be pre-determined and always evaluates to true/false
The predicate, identiﬁed by string, cannot possibly be other than what is indicated by the message. For example:

unsigned u; ... 
if( (u & 0x10) == 0x11 ) ...

would be greeted with the message that ’==’ always evaluates to ’false’.

See Precision, Viable Bit Patterns, and Representable Values for more information.
Supports AUTOSAR17 Rule M0-1-9
Supports AUTOSAR19 Rule M0-1-9
Supports MISRA C++:2008 Rule 0-1-9 - There shall be no dead code.

592
warning
non-literal format speciﬁer used without arguments
A printf/scanf style function received a non-literal format speciﬁer without trailing arguments. For example:

char msg[100]; 
... 
printf( msg );

This can easily be rewritten to the relatively safe:

char msg[100]; 
... 
printf( "%s", msg );

The danger lies in the fact that msg can contain hidden format codes. If msg is read from user input, then in the ﬁrst example, a naive user could cause a glitch or a crash and a malicious user might exploit this to undermine system security. Since the unsafe form can easily be transformed into the safe form, the latter should always be used.
Supports CERT C FIO30-C - Exclude user input from format strings
Supports CWE-20 - Improper Input Validation
Supports CWE-134 - Use of Externally-Controlled Format String

593
warning
custodial pointer symbol possibly not string nor returned
This is the ’possible’ version of message 429 . A pointer of auto storage class was allocated storage and not all paths leading to a return statement or to the end of the function contained either a free or a return of the pointer. Hence there is a potential memory leak. For example:

void f(int n) { 
   int *p = new int; 
   if (n) delete p; 
}                  //message 593

In this example an allocation is made and, if n is 0, no delete will have been made.

Please see message 429 for an explanation of "custodial" and ways of regulating when pointer variables retain custody of allocations.
Supports CWE-772 - Missing Release of Resource after Eﬀective Lifetime
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2025 Dir 4.13

597
warning
suspicious use of unary operator could be confused for compound assignment (string)
A construct such as:

a =- b;

a =+ b;

which is suspect: did the programmer intend to use the -=/+= compound assignment operator? The message is only issued when there is no space between the = and the -/+ and when there is a space between the -/+ and its operand. ’string’ contains the form of compound assignment that the expression may be confused for.

598
warning
excessive shift value (precision 'integer' shifted by 'integer')
A quantity is being shifted to the left by a value greater than or equal to the precision of that quantity or by a negative value. For example,

i << 32

will elicit this message if i is typed int and where int is 32 bits wide or less (the usual case). Such shift results in undeﬁned behavior. To suppress the message you may cast the shifted quantity to a type whose length is at least the length of the shift value.
Supports CWE-1335 - Incorrect Bitwise Shift of Integer

599
warning
cannot open ﬁle matching wild card pattern 'string'
A wild card pattern was used where the name of a ﬁle was expected but there were no ﬁles found that match the given pattern so it will be ignored. ’string’ contains the oﬀending pattern.

601
warning
expected a type, int assumed
A declaration did not have an explicit type. int was assumed. Was this a mistake? This could easily happen if an intended comma was replaced by a semicolon. For example, if instead of typing:

double     radius, 
          diameter;

the programmer had typed:

double     radius; 
          diameter;

this message would be raised.
Supports CERT C DCL31-C - Declare identiﬁers before using them
Supports MISRA C 2004 Rule 8.2 - Whenever an object or function is declared or deﬁned, its type shall be explicitly stated.
Supports MISRA C 2012 Rule 8.1 - Types shall be explicitly speciﬁed
Supports MISRA C:2023 Rule 8.1 - Types shall be explicitly speciﬁed
Supports MISRA C:2025 Rule 8.1

602
warning
'/*' within block comment
The sequence /* was found within a comment. Was this deliberate? Or was a comment end inadvertently omitted? If you want PC-lint Plus to recognize nested comments you should set the Nested Comment ﬂag using the +fnc option. Then this warning will not be issued. If it is your practice to use the sequence:

/* 
/*            */

then use -e602.
Supports AUTOSAR19 Rule M2-7-1
Supports CERT C MSC04-C - Use comments consistently and in a readable fashion
Supports MISRA C 2004 Rule 2.3 - The character sequence /* shall not be used within a comment.
Supports MISRA C 2004 Rule 2.4 - Sections of code should not be "commented out".
Supports MISRA C 2012 Dir 4.4 - Sections of code should not be "commented out"
Supports MISRA C 2012 Rule 3.1 - The character sequences /* and // shall not be used within a comment
Supports MISRA C:2023 Dir 4.4 - Sections of code should not be "commented out"
Supports MISRA C:2023 Rule 3.1 - The character sequences /* and // shall not be used within a comment
Supports MISRA C:2025 Dir 4.4
Supports MISRA C:2025 Rule 3.1
Supports MISRA C++:2008 Rule 2-7-1 - The character sequence /* shall not be used within a C-style comment.
Supports MISRA C++:2023 Rule 5.7.1 - The character sequence /* shall not be used within a C-style comment

603
warning
argument to parameter of type pointer to const may be a pointer to uninitialized memory
The address of the named symbol is being passed to a function where the corresponding parameter is declared as pointer to const. This implies that the function will not modify the object. If this is the case then the original object should have been initialized sometime earlier.
Supports CERT C EXP33-C - Do not read uninitialized memory
Supports CWE-457 - Use of Uninitialized Variable
Supports CWE-758 - Reliance on Undeﬁned, Unspeciﬁed, or Implementation-Deﬁned Behavior
Supports CWE-908 - Use of Uninitialized Resource
Supports MISRA C 2012 Rule 9.1 - The value of an object with automatic storage duration shall not be read before it has been set
Supports MISRA C:2023 Rule 9.1 - The value of an object with automatic storage duration shall not be read before it has been set
Supports MISRA C:2025 Rule 9.1

604
warning
returning address of auto variable symbol
The address of the named symbol is being passed back by a function. Since the object is an auto and since the duration of an auto is not guaranteed past the return, this is most likely an error. You may want to copy the value into a global variable and pass back the address of the global or you might consider having the caller pass an address of one of its own variables to the callee.
Supports AUTOSAR17 Rule M7-5-1
Supports AUTOSAR19 Rule M7-5-1
Supports CERT C DCL30-C - Declare objects with appropriate storage durations
Supports CWE-562 - Return of Stack Variable Address
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2004 Rule 17.6 - The address of an object with automatic storage shall not be assigned to another object that may persist after the ﬁrst object has ceased to exist.
Supports MISRA C 2012 Rule 18.6 - The address of an object with automatic storage shall not be copied to another object that persists after the ﬁrst object has ceased to exist
Supports MISRA C:2023 Rule 18.6 - The address of an object with automatic storage shall not be copied to another object that persists after the ﬁrst object has ceased to exist
Supports MISRA C:2025 Rule 18.6
Supports MISRA C++:2008 Rule 7-5-1 - A function shall not return a reference or a pointer to an automatic variable (including parameters), deﬁned within the function.
Supports MISRA C++:2023 Rule 6.8.2 - A function must not return a reference or a pointer to a local variable with automatic storage duration

605
warning
pointee implicitly gains/loses const/volatile qualiﬁer in conversion from type to type (context)
This warning is typically caused by assigning a (pointer to const) to an ordinary pointer. For example:

int *p; 
const int *q; 
p = q;    /* 605  */

The message will be inhibited if a cast is used as in:

p = (int *) q;

An increase in capability is indicated because the const pointed to by q can now be modiﬁed through p. This message can be given for the volatile qualiﬁer as well as the const qualiﬁer and may be given for arbitrary pointer depths (pointers to pointers, pointers to arrays, etc.).

If the number of pointer levels exceeds one, things get murky in a hurry. For example:

const char ** ppc; 
char ** pp; 
pp = ppc;       /* 605 - clearly not safe */ 
ppc = pp;       /* 605 - looks safe but it's not */

The problem is that after the above assignment, a pointer to a const char can be assigned indirectly through ppc and accessed through pp, which can then modify the const char.

The message speaks of an "increase in capability" in assigning to ppc, which seems counter intuitive because the indirect pointer has less capability. However, assigning the pointer does not destroy the old one and the combination of the two pointers represents a net increase in capability.

The message may also be given for function pointer assignments when the prototype of one function contains a pointer of higher capability than a corresponding pointer in another prototype. There is a curious inversion here whereby a prototype of lower capability translates into a function of greater trust and hence greater capability (a Trojan Horse). For example, let

void warrior( char * );

be a function that destroys its argument. Consider the function:

void Troy( void (*horse)(const char *) );\\

Troy() will call horse() with an argument that it considers precious (i.e. not to be modiﬁed) believing the horse() will do no harm. Before compilers knew better and believing that adding in a const to the destination never hurt anything, earlier compilers allowed the Greeks to pass warrior() to Troy and the rest, as they say, is history.

606
warning
non-ANSI escape sequence: '\string'
An escape sequence was encountered, within a character or string literal, that was not on the approved list, which consists of:

\’ \" \? \\ \a \b \f \n \r \t \u \U \v
\octal-digits \xhex-digits
Supports AUTOSAR17 Rule A2-14-1
Supports AUTOSAR19 Rule A2-13-1
Supports MISRA C 2004 Rule 4.1 - Only those escape sequences that are deﬁned in the ISO C standard shall be used.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3
Supports MISRA C++:2008 Rule 2-13-1 - Only those escape sequences that are deﬁned in ISO/IEC 14882:2003 shall be used.
Supports MISRA C++:2023 Rule 5.13.1 - Within character literals and non raw-string literals, \ shall only be used to form a deﬁned escape sequence or universal character name

608
warning
assigning to array parameter symbol
An assignment is being made to a parameter that is typed array. For the purpose of the assignment, the parameter is regarded as a pointer. Normally such parameters are typed as pointers rather than arrays. However if this is your coding style you should suppress this message.

611
warning
cast between pointer to function type type and pointer to object type type
Either a pointer to a function is being cast to a pointer to an object or vice versa. This is regarded as questionable by the language standards. If this is not a user error, suppress this warning.
Supports AUTOSAR17 Rule M5-2-6
Supports AUTOSAR19 Rule M5-2-6
Supports MISRA C++:2008 Rule 5-2-6 - A cast shall not convert a pointer to a function to any other pointer type, including a pointer to function type.

612
warning
declaration does not declare anything
A declaration contained just a storage class and a type. This is almost certainly an error since the only time a type without a declarator makes sense is in the case of a struct, union or enum but in that case you wouldn’t use a storage class.
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code

613
warning
potential use of null pointer symbol
From information gleaned from earlier statements, it is possible that a null pointer (a pointer whose value is 0) can be used in a context where null pointers are inappropriate. Information leading to this determination is provided as a series of supplemental messages. See also message 413 . This message can be emitted with additional parameterized text when the +fpn ﬂag is enabled and an instance of this message is reporting the use of a pointer parameter assumed to be NULL.
Supports AUTOSAR19 Rule A5-3-2
Supports AUTOSAR19 Rule A8-4-10
Supports CERT C EXP34-C - Do not dereference null pointers
Supports CERT C ARR00-C - Understand how arrays work
Supports CERT C ARR30-C - Do not form or use out-of-bounds pointers or array subscripts
Supports CERT C MEM11-C - Do not assume inﬁnite heap space
Supports CERT C API00-C - Functions should validate their parameters
Supports CERT C MSC19-C - For functions that return an array, prefer returning an empty array over a null value
Supports CERT C POS54-C - Detect and handle POSIX library errors
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports CWE-123 - Write-what-where Condition
Supports CWE-125 - Out-of-bounds Read
Supports CWE-127 - Buﬀer Under-read
Supports CWE-129 - Improper Validation of Array Index
Supports CWE-252 - Unchecked Return Value
Supports CWE-253 - Incorrect Check of Function Return Value
Supports CWE-391 - Unchecked Error Condition
Supports CWE-476 - NULL Pointer Dereference
Supports CWE-690 - Unchecked Return Value to NULL Pointer Dereference
Supports CWE-786 - Access of Memory Location Before Start of Buﬀer
Supports CWE-787 - Out-of-bounds Write

614
warning
auto aggregate initializer not constant
Prior to C99, auto aggregate initialization could consist only of constant expressions. This message is only issued in C89/C90 mode. See also message 446 .

615
warning
auto aggregate initializer has side eﬀects
This warning is similar to 614. Auto aggregates (arrays, structures and possibly unions) are normally initialized by a collection of constant expressions without side-eﬀects. If your compiler supports side-eﬀects in the initializers of aggregate, you may want to suppress this message. This message is only issued in C89/C90 mode.

616
warning
control ﬂow falls through to next case without an intervening comment
It is possible for ﬂow of control to fall into a case statement or a default statement from above. Was this deliberate or did the programmer forget to insert a break statement? If this was deliberate then place a comment immediately before the statement that was ﬂagged as in:

case 'a': a=0; 
   /* fall through */ 
case 'b':  a++;

Note that the message will not be given for a case that merely follows another case without an intervening statement. Also, there must actually be a possibility for ﬂow to occur from above. See also message 825 and option -fallthrough .
Supports CERT C MSC17-C - Finish every set of statements associated with a case label with a break statement
Supports CWE-484 - Omitted Break Statement in Switch
Supports MISRA C 2012 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C 2012 Rule 16.3 - An unconditional break statement shall terminate every switch-clause
Supports MISRA C:2023 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C:2023 Rule 16.3 - An unconditional break statement shall terminate every switch-clause
Supports MISRA C:2025 Rule 16.1
Supports MISRA C:2025 Rule 16.3

618
warning
storage class speciﬁed after a type
A storage class speciﬁer (static, extern, typedef, register or auto) was found after a type was speciﬁed. This is legal but unusual. Either place the storage class speciﬁer before the type or suppress this message.
Supports AUTOSAR17 Rule A7-1-8
Supports AUTOSAR19 Rule A7-1-8

620
warning
suspicious constant (L or one?)
A constant ended in a lower-case letter ’l’. Was this intended to be a one? The two characters look very similar. To avoid misinterpretations, use the upper-case letter ’L’.
Supports CERT C DCL16-C - Use "L," not "l," to indicate a long value
Supports MISRA C 2012 Rule 7.3 - The lowercase character "l" shall not be used in a literal suﬃx
Supports MISRA C:2023 Rule 7.3 - The lowercase character "l" shall not be used in a literal suﬃx
Supports MISRA C:2025 Rule 7.3
Supports MISRA C++:2023 Rule 5.13.5 - The lowercase form of L shall not be used as the ﬁrst character in a literal suﬃx

621
warning
identiﬁer clash (string): string 'string' clashes with string 'string'
The -idlen option can be used to specify the number of signiﬁcant characters in external, preprocessor, and preprocessor names. Names that are not unique within the initial characters speciﬁed by this option are said to "clash" and are reported by this message.

For the purpose of this message, identiﬁers are classiﬁed as external (function and variable names with external linkage), preprocessor (macro names and macro parameter names), and compiler (all other identiﬁers, including those with internal and no linkage, such as ﬁelds, tags, enumeration constants, typedefs, labels, etc). The type of clash is reported by the ﬁrst string parameter. The possible values of this parameter and the cases in which the clashes are reported are detailed in the following list.

field vs field
The names of two ﬁelds clash within the same structure or union.
tag vs tag
The names of two struction, union, or enum tags clash within a single translation unit.
label vs label
The names of two labels clash within a single function.
internal vs internal, same scope
Two compiler identiﬁers clash in the same scope.
internal vs external, same scope
A compiler identiﬁer clashes with an external identiﬁer in the same scope.
external vs internal, same scope
An external identiﬁer clashes with a compiler identiﬁer in the same scope.
internal vs internal, enclosing scope
A compiler identiﬁer clashes with another compiler identiﬁer in an enclosing scope.
internal vs external, enclosing scope
A compiler identiﬁer clashes with an external identiﬁer in an enclosing scope.
external vs internal, enclosing scope
An external identiﬁer clashes with a compiler identiﬁer in an enclosing scope.
external vs external
Two external identiﬁers clash (anywhere in the analyzed program).
macro vs macro
The names of two macros in the same translation unit clash.
macro vs macro parameter
The name of a macro clashes with the name of a macro parameter of a currently deﬁned macro.
macro parameter vs macro parameter
The name of a macro parameter clashes with the name of a parameter of the same macro.

Fields, tags, and labels each exist in their own name spaces and thus never clash with identiﬁers in other name spaces. Internal here refers to compiler identiﬁers that are not ﬁeld, tag, or label identiﬁers. For clashes between internal and external names, the number of signiﬁcant characters for compiler identiﬁers is used to determine a clash. Clashes between two external identiﬁers are reported regardless of scope. External identiﬁers in separate modules that clash are reported during global wrapup.

This message is not issued for C++ modules (all characters in identiﬁer names are signiﬁcant and case-sensitive in C++) or for identiﬁers with identical spelling.
Supports CERT C DCL23-C - Guarantee that mutually visible identiﬁers are unique
Supports CERT C DCL40-C - Do not create incompatible declarations of the same function or object
Supports MISRA C 2012 Rule 5.1 - External identiﬁers shall be distinct
Supports MISRA C 2012 Rule 5.2 - Identiﬁers declared in the same scope and name space shall be distinct
Supports MISRA C 2012 Rule 5.3 - An identiﬁer declared in an inner scope shall not hide an identiﬁer declared in an outer scope
Supports MISRA C 2012 Rule 5.4 - Macro identiﬁers shall be distinct
Supports MISRA C:2023 Rule 5.1 - External identiﬁers shall be distinct
Supports MISRA C:2023 Rule 5.2 - Identiﬁers declared in the same scope and name space shall be distinct
Supports MISRA C:2023 Rule 5.3 - An identiﬁer declared in an inner scope shall not hide an identiﬁer declared in an outer scope
Supports MISRA C:2023 Rule 5.4 - Macro identiﬁers shall be distinct
Supports MISRA C:2025 Rule 5.1
Supports MISRA C:2025 Rule 5.2
Supports MISRA C:2025 Rule 5.3
Supports MISRA C:2025 Rule 5.4

629
warning
'static' function declaration at block scope is non standard
A static storage class speciﬁer was found for a function declaration within a function. The static storage class speciﬁer is permitted only for functions in declarations that have ﬁle scope (i.e., outside any function). Either move the declaration outside the function or change static to extern; if the second choice is made, make sure that a static declaration at ﬁle scope also exists before the extern declaration.
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

631
warning
tag symbol deﬁned diﬀerently at location
The struct, union or enum tag symbol was deﬁned diﬀerently in diﬀerent scopes. This is not necessarily an error since C permits the redeﬁnition, but it can be a source of subtle error. It is not generally a programming practice to be recommended. This message is suppressed for unit checkout (-unit_check option).
Supports MISRA C 2012 Rule 5.7 - A tag name shall be a unique identiﬁer
Supports MISRA C:2023 Rule 5.7 - A tag name shall be a unique identiﬁer
Supports MISRA C:2025 Rule 5.7
Supports MISRA C++:2023 Rule 6.2.1 - The one-deﬁnition rule shall not be violated

632
warning
strong type mismatch: assigning 'strong-type' to 'strong-type' in context 'context'
An assignment (or implied assignment, context indicates which), violates a Strong type check as requested by a -strong(A...) option. See Chapter 7 Strong Types .

633
warning
strong type mismatch: extracting 'strong-type' into 'strong-type' in context 'context'
An assignment (or implied assignment, context indicates which), violates a Strong type check as requested by a -strong(X...) option. See Chapter 7 Strong Types .

634
warning
strong type mismatch: cannot join 'strong-type' and 'strong-type' using operator 'operator'
An equality operation (== or !=) or a conditional operation (? :) violates a Strong type check as requested by a -strong(J...) option. This message would have been suppressed using ﬂags "Je". See Chapter 7 Strong Types .

635
warning
changing the parent/index type of 'strong-type' from 'strong-type' to 'strong-type'
The strong parent of the symbol is being reset. This is being done with a -parent option or by a typedef. Note that this may not necessarily be an error; you are being alerted to the fact that the old link is being erased. See Chapter 7 Strong Types .

636
warning
strong type diﬀerence: pointees are 'strong-type' and 'strong-type'
Pointers are being compared and there is a strong type clash below the ﬁrst level. For example,

/*lint -strong(J, INT) */ 
typedef int INT; 
INT *p;  int *q; 
 
if( p == q ) /*  Warning 636  */

will elicit this warning. This message would have been suppressed using ﬂags "Je" or "Jr" or both. See Chapter 7 Strong Types .

637
warning
strong type mismatch: 'strong-type' is not an acceptable index type for 'strong-type' (expected 'strong-type')
This is the message you receive when an inconsistency with the -index option is recognized. A subscript is not the stipulated type (the ﬁrst type mentioned in the message) nor equivalent to it within the hierarchy of types. See Chapter 7 Strong Types and also +fhx .

638
warning
strong type mismatch: cannot join 'strong-type' and 'strong-type' using operator 'operator'
A relational operation ( >= <= > < ) violates a Strong type check as requested by a -strong(J...) option. This message would have been suppressed using ﬂags "Jr". See Chapter 7 Strong Types .

639
warning
strong type mismatch: cannot join 'strong-type' and 'strong-type' using operator 'operator'
A binary operation other than an equality or a relational operation violates a Strong type check as requested by a -strong(J...) option. This message would have been suppressed using ﬂags "Jo". See Chapter 7 Strong Types .

640
warning
strong type mismatch: 'strong-type' is not an acceptable boolean type for parameter 'keyword' statement (expected 'strong-type')
A Boolean context expected a type speciﬁed by a -strong(B...) option. See Chapter 7 Strong Types .

641
warning
implicit conversion of enum symbol to integral type type
An enumeration type was used in a context that required a computation such as an argument to an arithmetic operator or was compared with an integral argument. This warning will be suppressed if you use the integer model of enumeration (+fie ) but you will lose some valuable type-checking in doing so. An intermediate policy is to simply turn oﬀ this warning. Assignment of int to enum will still be caught.

This warning is not issued for a tagless enum without variables. For example

enum {false,true};

This cannot be used as a separate type. PC-lint Plus recognizes this and treats false and true as arithmetic constants.

644
warning
potentially using an uninitialized value
An auto variable was not necessarily assigned a value before use.
Supports CERT C EXP33-C - Do not read uninitialized memory
Supports CWE-456 - Missing Initialization of a Variable
Supports CWE-457 - Use of Uninitialized Variable
Supports CWE-758 - Reliance on Undeﬁned, Unspeciﬁed, or Implementation-Deﬁned Behavior
Supports CWE-908 - Use of Uninitialized Resource
Supports MISRA C 2004 Rule 9.1 - All automatic variables shall have been assigned a value before being used.
Supports MISRA C 2012 Rule 9.1 - The value of an object with automatic storage duration shall not be read before it has been set
Supports MISRA C:2023 Rule 9.1 - The value of an object with automatic storage duration shall not be read before it has been set
Supports MISRA C:2025 Rule 9.1

646
warning
'string' within 'string' loop; may have been misplaced
A case or default statement was found within a for, do, or while loop. Was this intentional? At the very least, this reﬂects poor programming style.
Supports CERT C MSC20-C - Do not use a switch statement to transfer control into a complex block

647
warning
possible truncation before conversion from type to type
This message is issued when it appears that there may have been an unintended loss of information during an operation involving int or unsigned int the result of which is later converted to long. It is issued only for systems in which int is smaller than long. For example:

(long) (n << 8)

might elicit this message if n is unsigned int, whereas

(long) n << 8

would not. In the ﬁrst case, the shift is done at int precision and the high order 8 bits are lost even though there is a subsequent conversion to a type that might hold all the bits. In the second case, the shifted bits are retained.

The operations that are scrutinized and reported upon by this message are: shift left, multiplication, and bit-wise complementation. Addition and subtraction are covered by Informational message 776 .

The conversion to long may be done explicitly with a cast as shown or implicitly via assignment, return, argument passing or initialization.

The message can be suppressed by casting. You may cast one of the operands so that the operation is done in full precision as is given by the second example above. Alternatively, if you decide there is really no problem here (for now or in the future), you may cast the result of the operation to some form of int. For example, you might write:

(long) (unsigned) (n << 8)

In this way PC-lint Plus will know you are aware of and approve of the truncation.

648
warning
overﬂow in computing constant for operator 'operator'
Arithmetic overﬂow was detected while computing a constant expression. For example, if int is 16 bits then 200 * 200 will result in an overﬂow.

To suppress this message for particular constant operations you may have to supply explicit truncation. For example, if you want to obtain the low order 8 bits of the integer 20000 into the high byte of a 16-bit int, shifting left would cause this warning. However, truncating ﬁrst and then shifting would be OK. The following code illustrates this where int is 16 bits.

20000u << 8;          /* 648 */ 
(0xFF & 20000u) << 8;  /* OK */

If you truncate with a cast you may make a signed expression out of an unsigned. For example, the following receives a warning (for 16 bit int).

(unsigned char) 0xFFFu << 8;    /* 648 */

because the unsigned char is promoted to int before shifting. The resulting quantity is actually negative. You would need to revive the unsigned nature of the expression with

(unsigned) (unsigned char) 0xFFF << 8;    /* OK */

Supports CERT C INT08-C - Verify that all integer values are in range

649
warning
right shifting a negative constant expression has implementation deﬁned behavior
During the evaluation of a constant expression, a negative integer was shifted right causing sign ﬁll of vacated positions. If this is what is intended, suppress this error, but be aware that sign ﬁll is implementation-dependent.

650
warning
constant 'integer' out of range for operator 'string'
In a comparison operator or equality test (or implied equality test as for a case statement), a constant operand was used in a way that is not appropriate for the constraints on the value of the other operand. For example, if 300 is compared against a char variable, this warning will be issued. Moreover, if char is signed (and 8 bits) you will get this message if you compare against an integer greater than 127. The problem can be ﬁxed with a cast. For example:

if( ch == 0xFF ) ... 
if( (unsigned char) ch == 0xFF ) ...

If char is signed (+fcu has not been set) the ﬁrst receives a warning and can never succeed. The second suppresses the warning and corrects the bug.

PC-lint Plus will take into account the limited precision of some operands such as bit-ﬁelds and enumerated types. Also, PC-lint Plus will take advantage of computations that limit the precision of an operand. For example,

if( (n & 0xFF) >> 4 == 16 ) ...}

will receive this warning because the left-hand side is limited to 4 bits of precision.

See Precision, Viable Bit Patterns, and Representable Values for more information. See also message 2650 for constants that are out of range for only part of a compound comparison operator.
Supports CERT C INT08-C - Verify that all integer values are in range
Supports MISRA C 2004 Rule 13.7 - Boolean operations whose results are invariant shall not be permitted.
Supports MISRA C 2012 Rule 14.3 - Controlling expressions shall not be invariant
Supports MISRA C:2023 Rule 14.3 - Controlling expressions shall not be invariant
Supports MISRA C:2025 Rule 14.3
Supports MISRA C++:2023 Rule 0.0.2 - Controlling expressions should not be invariant

651
warning
inconsistent bracing in aggregate initialization
An initializer for a complex aggregate is being processed that contains some subaggregates that are bracketed and some that are not. ANSI/ISO recommends either "minimally bracketed" initializers in which there are no interior braces or "fully bracketed" initializers in which all interior aggregates are bracketed.

652
warning
#deﬁne of macro 'string' with same name as previously declared symbol symbol
A macro is being deﬁned for a symbol that had previously been declared. For example:

int n; 
#define n N

will draw this complaint. Prior symbols checked are local and global variables, functions and typedef symbols, and struct, union and enum tags. Not checked are struct and union members.

653
warning
result of integer division being converted to type
When two integers are divided and assigned to a ﬂoating point variable the fraction portion is lost. For example, although

double x = 5 / 2;

appears to assign 2.5 to x it actually assigns 2.0. To make sure you do not lose the fraction, cast at least one of the operands to a ﬂoating point type. If you really wish to do the truncation, cast the resulting divide to an integral (int or long) before assigning to the ﬂoating point variable.
Supports CERT C FLP06-C - Convert integers to ﬂoating point for ﬂoating-point operations

654
warning
option 'option' is obsolete; detail
The speciﬁed option is obsolete and should no longer be used. The detail parameter contains additional information such as further explanation or alternatives.

655
warning
bitwise operation uses compatible enums (of type type)
A bit-wise operator (one of ’|’, ’&’ or ’^’) is used to combine two compatible enumerations. The type of the result is considered to be the enumeration. This is considered a very minor deviation from the strict model and you may elect to suppress this warning.

656
warning
arithmetic operation uses compatible enums (of type type)
An arithmetic operator (one of ’+’, or ’-’) is used to combine two compatible enumerations. The type of the result is considered to be the enumeration. This is considered a very minor deviation from the strict model and you may elect to suppress this warning.

657
warning
unusual (nonportable) anonymous struct or union
A struct or union declaration without a declarator was taken to be anonymous. However, the anonymous union supported by C++ and other dialects of C require untagged unions. Tagged unions and tagged or untagged structs are rarely supported, as anonymous.

658
warning
anonymous union assumed (use ﬂag +fan)
A union without a declarator was found. Was this an attempt to deﬁne an anonymous union? If so, anonymous unions should be activated with the +fan ﬂag. This ﬂag is activated automatically for C++.

660
warning
option 'string' requests removing an extent that is not on the list
A number of options use the ’-’ preﬁx to remove and the ’+’ preﬁx to add elements to a list. For example to add (the most unusual) extension .C++ to designate C++ processing of ﬁles bearing that extension, a programmer should employ the option:

+cpp(.C++)

However, if a leading ’-’ is employed (a natural mistake) this warning will be emitted.

661
warning
potential out of bounds pointer access: excess of integer byte(s)
An out-of-bounds pointer may have been accessed. See message 415 for a description of the integer parameter. For example:

int a[10]; 
if( n <= 10 ) a[n] = 0;

Here the programmer presumably should have written n < 10. This message is similar to message 415 but diﬀers from it by the degree of probability. See Chapter 8 Value Tracking .
Supports AUTOSAR17 Rule M5-0-16
Supports AUTOSAR17 Rule A5-2-5
Supports AUTOSAR19 Rule M5-0-16
Supports AUTOSAR19 Rule A5-2-5
Supports CERT C ARR30-C - Do not form or use out-of-bounds pointers or array subscripts
Supports CERT C MSC19-C - For functions that return an array, prefer returning an empty array over a null value
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports CWE-123 - Write-what-where Condition
Supports CWE-125 - Out-of-bounds Read
Supports CWE-126 - Buﬀer Over-read
Supports CWE-127 - Buﬀer Under-read
Supports CWE-129 - Improper Validation of Array Index
Supports CWE-786 - Access of Memory Location Before Start of Buﬀer
Supports CWE-787 - Out-of-bounds Write
Supports MISRA C 2012 Rule 18.1 - A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
Supports MISRA C:2023 Rule 18.1 - A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
Supports MISRA C:2025 Rule 18.1
Supports MISRA C++:2008 Rule 5-0-16 - A pointer operand and any pointer resulting from pointer arithmetic using that operand shall both address elements of the same array.

662
warning
possibly creating out-of-bounds pointer: excess of integer byte(s)
An out-of-bounds pointer may have been created. See message 415 for a description of the integer parameter. For example:

int a[10]; 
if( n <= 20 ) f( a + n );

Here, it appears as though an illicit pointer is being created, but PC-lint Plus cannot be certain. See also message 416 and Chapter 8 Value Tracking .
Supports AUTOSAR17 Rule M5-0-16
Supports AUTOSAR17 Rule A5-2-5
Supports AUTOSAR19 Rule M5-0-16
Supports AUTOSAR19 Rule A5-2-5
Supports CERT C ARR30-C - Do not form or use out-of-bounds pointers or array subscripts
Supports CERT C MSC19-C - For functions that return an array, prefer returning an empty array over a null value
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports CWE-123 - Write-what-where Condition
Supports CWE-125 - Out-of-bounds Read
Supports CWE-126 - Buﬀer Over-read
Supports CWE-127 - Buﬀer Under-read
Supports CWE-129 - Improper Validation of Array Index
Supports CWE-786 - Access of Memory Location Before Start of Buﬀer
Supports CWE-787 - Out-of-bounds Write
Supports MISRA C 2012 Rule 18.1 - A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
Supports MISRA C:2023 Rule 18.1 - A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
Supports MISRA C:2025 Rule 18.1
Supports MISRA C++:2008 Rule 5-0-16 - A pointer operand and any pointer resulting from pointer arithmetic using that operand shall both address elements of the same array.

663
warning
array-to-pointer decay causes indirection through ﬁrst element
This warning occurs in the following kind of situation:

struct x { int a; } y[2]; 
...  y->a  ...

Here, the programmer forgot to index the array but the error normally goes undetected because the array reference is automatically and implicitly converted to a pointer to the ﬁrst element of the array. If you really mean to access the ﬁrst element use y[0].a

664
warning
left hand side of logical operator contains call to function that does not return
An exiting function was found on the left hand side of an operator implying that the right hand side would never be executed. For example:

if( (exit(0), n == 0) || n > 2 ) ...

Since the exit function does not return, control can never ﬂow to the right hand operator.

665
warning
unparenthesized parameter integer in macro 'string' is passed an expression
An expression was passed to a macro parameter that was not parenthesized. For example:

#define mult(a,b) (a*b) 
...  mult( 100, 4 + 10 )

Here the programmer is beguiled into thinking that the 4+10 is taken as a quantity to be multiplied by 100 but instead results in: 100*4+10, which is quite diﬀerent. The recommended remedy ([?, Section 19.4]) is to parenthesize such parameters as in:

#define mult(a,b) ((a)*(b))

The message is not arbitrarily given for any unparenthesized parameter but only when the actual macro argument suﬃciently resembles an expression and the expression involves binary operators. The priority of the operator is not considered except that it must have lower priority than the unary operators. The message is not issued at the point of macro deﬁnition because it may not be appropriate to parenthesize the parameter. For example, the following macro expects that an operator will be passed as argument. It would be an error to enclose op in parentheses.

#define check(x,op,y) if( ((x) op (y)) == 0 ) print( ... )

Supports MISRA C 2012 Rule 20.7 - Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses
Supports MISRA C:2023 Rule 20.7 - Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses
Supports MISRA C:2025 Rule 20.7
Supports MISRA C++:2023 Rule 19.3.4 - Parentheses shall be used to ensure macro arguments are expanded appropriately

666
warning
expression with side eﬀects passed to repeated parameter integer of macro 'string'
A repeated parameter within a macro was passed an argument with side-eﬀects. For example:

#define ABS(x) ((x) < 0 ? -(x) : (x)) 
 
... ABS( n++ )

Although the ABS macro is correctly deﬁned to specify the absolute value of its argument, the repeated use of the parameter x implies a repeated evaluation of the actual argument n++ This results in two increments to the variable n. [?, Section 19.6] Any expression containing a function call is also considered to have side-eﬀects.
Supports CERT C PRE31-C - Avoid side eﬀects in arguments to unsafe macros

668
warning
possibly passing null pointer to function symbol, context
A NULL pointer is possibly being passed to a function identiﬁed by symbol. The argument in question is given by context. The function is either a library function designed not to receive a NULL pointer or a user function dubbed so via the option -function or -sem . See Sections 9.1 Function Mimicry (-function) , 9.2 Semantic Speciﬁcations and 8 Value Tracking . This message can be emitted with additional parameterized text when the +fpn ﬂag is enabled and an instance of this message is reporting the use of a pointer parameter assumed to be NULL.
Supports AUTOSAR19 Rule A8-4-10
Supports CERT C EXP34-C - Do not dereference null pointers
Supports CERT C API00-C - Functions should validate their parameters
Supports CERT C MSC19-C - For functions that return an array, prefer returning an empty array over a null value
Supports CWE-476 - NULL Pointer Dereference
Supports CWE-690 - Unchecked Return Value to NULL Pointer Dereference
Supports MISRA C 2004 Rule 20.3 - The validity of values passed to library functions shall be checked.
Supports MISRA C 2012 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2023 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2025 Dir 4.11

669
warning
possible data overrun for function symbol, string (size=string) exceeds string (size=string)
This message is for data transfer functions such as memcpy, strcpy, fgets, etc. when the size indicated by the ﬁrst cited argument (or arguments) can possibly exceed the size of the buﬀer area cited by the second. The message may also be issued for user functions via the -function or -sem option. See Sections 9.1 Function Mimicry (-function) , 9.2 Semantic Speciﬁcations and Chapter 8 Value Tracking .
Supports CERT C ENV01-C - Do not make assumptions about the size of an environment variable
Supports CERT C MSC19-C - For functions that return an array, prefer returning an empty array over a null value
Supports MISRA C 2004 Rule 20.3 - The validity of values passed to library functions shall be checked.
Supports MISRA C 2012 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2023 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2025 Dir 4.11

670
warning
possible access beyond array for function symbol, string (size=string) exceeds string (size=string)
This message is issued for several library functions (such as fwrite, memcmp, etc.) wherein there is a possible attempt to access more data than exist. For example, if the length of data speciﬁed in the fwrite call exceeds the size of the data speciﬁed. The function is speciﬁed by symbol and the arguments are identiﬁed by argument number. See Sections 9.1 Function Mimicry (-function) , 9.2 Semantic Speciﬁcations and Chapter 8 Value Tracking .
Supports CERT C MSC19-C - For functions that return an array, prefer returning an empty array over a null value
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports MISRA C 2004 Rule 20.3 - The validity of values passed to library functions shall be checked.
Supports MISRA C 2012 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2023 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2025 Dir 4.11

671
warning
possibly passing to function symbol a negative value (string) context
An integral value that may possibly be negative is being passed to a function that is expecting only positive values for a particular argument. The message contains the name of the function (symbol), the questionable value (integer) and the argument number (context). The function may be a standard library function designed to accept only positive values such as malloc or memcpy (third argument), or may have been identiﬁed by the user as such through the -function or -sem options. See message 422 for an example and further explanation.
Supports CWE-687 - Function Call With Incorrectly Speciﬁed Argument Value
Supports MISRA C 2004 Rule 20.3 - The validity of values passed to library functions shall be checked.
Supports MISRA C 2012 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2023 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2025 Dir 4.11

672
warning
assignment to custodial pointer symbol possibly creates memory leak
An assignment was made to a pointer variable (designated by symbol), which may already be holding the address of an allocated object that had not been freed. The allocation of memory, which is not freed, is considered a ’memory leak’. The memory leak is considered ’possible’ because only some lines of ﬂow will result in a leak.
Supports CWE-772 - Missing Release of Resource after Eﬀective Lifetime

673
warning
string may not be appropriate for deallocating string
This message indicates that a deallocation (delete, delete[], or free) as speciﬁed by the ﬁrst string parameter may be inappropriate for the data being freed. The kind of data is described in the second string parameter. The wording ’may not’ is used to indicate that only some of the lines of ﬂow to the deallocation show data inconsistent with the allocation. See also message 424 .
Supports CERT C MEM34-C - Only free memory allocated dynamically
Supports CWE-404 - Improper Resource Shutdown or Release
Supports CWE-590 - Free of Memory not on the Heap
Supports CWE-762 - Mismatched Memory Management Routines

674
warning
returning address of auto variable symbol through pointer symbol
The value held by a pointer variable contains the address of an auto variable. It is normally incorrect to return the address of an item on the stack because the portion of the stack allocated to the returning function is subject to being obliterated after return.
Supports CERT C DCL30-C - Declare objects with appropriate storage durations
Supports CWE-562 - Return of Stack Variable Address

675
warning
no prior semantics associated with 'name' in option 'string'
The -function option is used to transfer semantics from its ﬁrst argument to subsequent arguments. However it was found that the ﬁrst argument name did not have semantics.

676
warning
possibly indexing before the beginning of an allocation
An integer whose value was possibly negative was added to an array or to a pointer to an allocated area (allocated by malloc, operator new, etc.). This message is not given for pointers whose origin is unknown since a negative subscript is in general legal.
Supports CERT C ARR30-C - Do not form or use out-of-bounds pointers or array subscripts
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports CWE-123 - Write-what-where Condition
Supports CWE-124 - Buﬀer Underwrite (‘Buﬀer Underﬂow’)
Supports CWE-125 - Out-of-bounds Read
Supports CWE-126 - Buﬀer Over-read
Supports CWE-127 - Buﬀer Under-read
Supports CWE-129 - Improper Validation of Array Index
Supports CWE-786 - Access of Memory Location Before Start of Buﬀer
Supports CWE-787 - Out-of-bounds Write
Supports CWE-839 - Numeric Range Comparison Without Minimum Check
Supports MISRA C 2012 Rule 18.1 - A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
Supports MISRA C:2023 Rule 18.1 - A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
Supports MISRA C:2025 Rule 18.1

677
warning
sizeof used within preprocessor statement
Whereas the use of sizeof during preprocessing is supported by a number of compilers it is not a part of the ANSI/ISO C or C++ standard. See Section 18.6 Preprocessor sizeof .

678
warning
member symbol ﬁeld length (integer) too small for enum precision (integer)
A bit ﬁeld was found to be too small to support all the values of an enumeration (that was used as the base of the bit ﬁeld). For example:

enum color { red, green, yellow, blue }; 
struct abc { enum color c:2; };

Here, the message is not given because the four enumeration values of color will just ﬁt within 2 bits. However, if one additional color is inserted, Warning 678 will be issued informing the programmer of the undesirable and dangerous condition.
Supports MISRA C++:2023 Rule 12.2.2 - A bit-ﬁeld shall have an appropriate type

679
warning
integer operation may be truncated before being combined with a larger pointer type
This message is issued when it appears that there may have been an unintended loss of information during an operation involving integrals before combining with a pointer whose precision is greater than the integral expression. For example:

// Assuming 4-byte ints and 8-bytes pointers (-si4 -sp8) 
char *f( char *p, int n, int m ) { 
   return p + (n + m); // warning 679 
}

By the rules of C/C++, the addition n+m is performed independently of its context and is done at integer precision. Any overﬂow is ignored even though the larger precision of the pointer could easily accommodate the overﬂow. If, on the other hand the expression were: p+n+m, which parses as (p+n)+m, no warning would be issued.

If the expression were p+n*m then, to suppress the warning, a cast is needed. If long were the same size as pointers you could use the expression:

return p + ((long) n * m);

Supports CERT C INT08-C - Verify that all integer values are in range

680
warning
suspicious truncation in arithmetic expression converted to pointer
An arithmetic expression was cast to pointer. Moreover, the size of the pointer is greater than the size of the expression. In computing the expression, any overﬂow would be lost even though the pointer type would be able to accommodate the lost information. To suppress the message, cast one of the operands to an integral type large enough to hold the pointer. Alternatively, if you are sure there is no problem you may cast the expression to an integral type before casting to pointer. See messages 647 , 776 , 790 and 679 .
Supports CERT C INT08-C - Verify that all integer values are in range

681
warning
loop is likely not entered
The controlling expression for a loop (either the expression within a while clause or the second expression within a for clause) evaluates initially to 0 and so it appears as though the loop is never entered.
Supports AUTOSAR17 Rule M0-1-1
Supports AUTOSAR19 Rule M0-1-1
Supports CWE-561 - Dead Code
Supports MISRA C 2004 Rule 14.1 - There shall be no unreachable code.
Supports MISRA C 2012 Rule 2.1 - A project shall not contain unreachable code
Supports MISRA C:2023 Rule 2.1 - A project shall not contain unreachable code
Supports MISRA C:2025 Rule 2.1
Supports MISRA C++:2008 Rule 0-1-1 - A project shall not contain unreachable code.
Supports MISRA C++:2023 Rule 0.0.1 - A function shall not contain unreachable statements

682
warning
sizeof applied to parameter symbol of function symbol whose type is a sized array will yield size of string instead of string
If a parameter is typed as an array it is silently promoted to pointer. Taking the size of such an array will actually yield the size of a pointer. Consider, for example:

unsigned f( char a[100] ) { return sizeof(a); }

Here it looks as though function f() will return the value 100 but it will actually return the size of a pointer, which is usually 4.
Supports CERT C ARR01-C - Do not apply the sizeof operator to a pointer when taking the size of an array
Supports CWE-467 - Use of sizeof() on a Pointer Type
Supports MISRA C 2012 AMD1 Rule 12.5 - The sizeof operator shall not have an operand which is a function parameter declared as "array of type"
Supports MISRA C:2023 Rule 12.5 - The sizeof operator shall not have an operand which is a function parameter declared as "array of type"
Supports MISRA C:2025 Rule 12.5

683
warning
function 'string' #deﬁne'd, semantics may be lost
This message is issued whenever the name of a function with some semantic association is deﬁned as a macro. For example:

#define strlen mystrlen

will raise this message. The problem is that the semantics deﬁned for strlen will then be lost. Consider this message an alert to transfer semantics from strlen to mystrlen, using -function(strlen, mystrlen). The message will be issued for built-in functions (with built-in semantics) or for user-deﬁned semantics. The message will not be issued if the function is deﬁned to be a function with a similar name but with underscores either appended or prepended or both. For example:

#define strlen __strlen

will not produce this message. It will produce Info 828 instead.

685
warning
relational operator 'string' always evaluates to 'string'
The ﬁrst string is one of ’>’, ’>=’, ’<’, or ’<=’ and identiﬁes the relational operator. The second string is one of true or false. The message is given when an expression is compared to a constant and the precision of the expression indicates that the test will always succeed or always fail. For example,

char ch; 
... 
if( ch >= -128 ) ...

In this example, the precision of char ch is 8 bits signed (assuming the fcu ﬂag has been left in the OFF state) and hence it has a range of values from -128 to 127 inclusive. Hence the test is always true.

Note that, technically, ch is promoted to int before comparing with the constant. For the purpose of this comparison we consider only the underlying precision. As another example, if u is an unsigned int then

if( (u & 0xFF) > 0xFF ) ...

will also raise message 685 because the expression on the left hand side has an eﬀective precision of 16 bits.
Supports AUTOSAR17 Rule M0-1-1
Supports AUTOSAR17 Rule M0-1-2
Supports AUTOSAR17 Rule M0-1-9
Supports AUTOSAR19 Rule M0-1-1
Supports AUTOSAR19 Rule M0-1-2
Supports AUTOSAR19 Rule M0-1-9
Supports CWE-570 - Expression is Always False
Supports CWE-571 - Expression is Always True
Supports MISRA C 2004 Rule 13.7 - Boolean operations whose results are invariant shall not be permitted.
Supports MISRA C 2012 Rule 14.3 - Controlling expressions shall not be invariant
Supports MISRA C:2023 Rule 14.3 - Controlling expressions shall not be invariant
Supports MISRA C:2025 Rule 14.3
Supports MISRA C++:2008 Rule 0-1-1 - A project shall not contain unreachable code.
Supports MISRA C++:2008 Rule 0-1-2 - A project shall not contain infeasible paths.
Supports MISRA C++:2008 Rule 0-1-9 - There shall be no dead code.
Supports MISRA C++:2023 Rule 0.0.2 - Controlling expressions should not be invariant

686
warning
option 'option' is suspicious: detail
An option is considered suspicious for one of a variety of reasons. The reason is designated by detail. At this writing the following reasons for issuing this message are:

unbalanced quotes
An option was seen with a quote character that was not balanced within that same option.
backtick preceding non-meta character is superfluous and has been dropped
A backtick (`) was seen before a character other than a * or a ?. The use of a backtick in this fashion has no eﬀect.
upper case characters within extension ’string’; these will match lower case when +fff is on; try -fff
A ﬁle extension involving uppercase letters was seen in a +cpp or +lnt option while the +fff ﬂag was active or the ﬂag became active while there were uppercase extensions registered via +cpp or +lnt. If, for example, you intend for .c to indicate a C module and .C to indicate a C++ module, turning oﬀ the fff ﬂag will help avoid unnecessary complaints from PC-lint Plus.
extraneous characters following string
One or more characters were seen immediately following a character that is expected to signify the end of an option, such as a closing right parenthesis. While the extraneous characters are ignored, their presence may indicate a typographical error.
the likelihood of causing meaningless output
An option, such as -elib(*) , -wlib(0) , or +fce was seen; this typically hides a problem in the PC-lint Plus conﬁguration. When using a new conﬁguration, it’s common for a user to encounter Error messages about Library header code. (This usually does not indicate a problem with library headers.) For example, a misconﬁguration of PC-lint Plus preprocessor is by far the most common source of these errors. If you merely suppress basic Syntax Errors (like error 10 ) and/or Fatal Errors (like error 309 ), the underlying conﬁguration problem still exists; as a result, PC-lint Plus will fail to parse your code correctly (because your code depends on the aforementioned library code). The output from Lint would then seem illogical and/or meaningless. Therefore, blanket suppression options like this are highly discouraged. Instead, other aspects of the Lint conﬁguration should be modiﬁed to make Lint’s behavior more similar to that of the compiler at (or, typically, before) the point of Error.
it is too late to use -incvar as ’name’ has already been processed as incvar
This option (-incvar ) is used to specify the name of the environment variable that contains a list of supplementary directories to be searched for headers. This option does not have any eﬀect after this environment variable is processed, which occurs when processing the ﬁrst module. To have an eﬀect, the option must be moved to before the ﬁrst module.
option has no effect due to zero length zone of transition
The -w# or -wlib(#) option was seen with the same warning level of the previously provided -w# or -wlib(#) option. Because the warning level doesn’t change, there is no zone of transition and therefore no eﬀect on the message suppression set. For example, in -w1 +e714 -w1, the second -w1 does not have any eﬀect, in particular, message 714 is not suppressed because there is no zone of transition. If the goal is to suppress all messages except for errors regardless of messages that have been enabled in the meantime, it is necessary to raise the warning level and then lower it, e.g. -w4 -w1.
modifying the LINT environment variable after startup has no effect; this variable should be set before program startup
The -setenv option was used to set the LINT environment variable. If this variable is set when PC-lint Plus is started, its contents are processed as options before the command line options are processed. Attempting to set or change the value of this variable after program startup has no eﬀect.
-max_threads option must appear before first module to have any effect
The -max_threads option is used to specify the maximum concurrent linting threads to dispatch when performing parallel analysis. This option has no eﬀect when it appears after the ﬁrst module; move the option to before the ﬁrst module is referenced to obtain the desired behavior.
the size of an incomplete type was requested in a function semantic
The use of @p was used in a user-deﬁned function return semantic but the pointee return type was not complete at the point of the call. This is suspicious because if the type is incomplete, PC-lint Plus cannot calculate its size from the number of the type’s elements. Either use @P to specify size in bytes or make a deﬁnition of the type visible to PC-lint Plus at the point of the call.
the ’-i’ option is used to specify search directories, ’-include’ will add ’nclude’ to the directory search list; use the -header option to auto-include files
The option -include was seen. The likely intention was to cause a particular ﬁle to be auto-included as some compilers support this feature with an option of the same name. The PC-lint Plus option to auto-include ﬁles is -header .
the ’-i’ option is used to specify search directories, use the -header option to auto-include files
An option starting with -include= was seen. The likely intention was to cause the ﬁle following the = to be auto-included as some compilers support this feature with an option of the same name. The PC-lint Plus option to auto-include ﬁles is -header .
path refers to a file rather than a directory
The path provided to a -i or -I option was a valid path but refers to a ﬁle rather than a directory.
path is not accessible
The path provided to a -i or -I option does not exist or is otherwise inaccessible.
path begins with unexpanded tilde prefix
The path provided to a -i or -I option began with a tilde (~). This was likely intended to refer to the user’s home directory, but it is interpreted literally unless expanded by the shell.
path resembles a header file name
The argument to a -i or -I option ended with an extension that is commonly used for header ﬁle names such as .h, .hpp, or .hxx and did not correspond to a directory. The argument to a -i option should be a directory path, not a ﬁle path.
language standard cannot be changed while processing a module
A -std option was encountered within a conﬁguration ﬁle opened by -indirect or -subfile while processing a module. This option will have no eﬀect in this context but would be valid if the conﬁguration ﬁle were used outside of a module. Note that an attempt to change the language standard directly within a module, e.g. using a -std option within a comment, is always invalid and error 72 will be reported instead.
MISRA diagnostics are no longer issued via message ’msg’
A message pattern contained one of 960, 961, 1960, or 1963 which were messages used by PC-lint 9 to issue various MISRA diagnostics. These messages do not exist in PC-lint Plus which instead employs messages speciﬁc to individual MISRA guidelines. Options referencing these obsolete messages should be updated.
message ’msg’ is deprecated and will be removed in a future version
The speciﬁed deprecated message number was encountered in a message pattern. Deprecated messages will eventually be removed from PC-lint Plus and should not be used. See the description of the cited message number for more speciﬁc guidance.
the value of the ’flo’ flag cannot be changed within a module
An attempt was made to change the value of the flo ﬂag using +flo, ++flo, -flo, or –flo within a module. The value of the flo ﬂag should only be changed outside a module and these options will have no eﬀect when encountered in a module.
option indirectly changes state of ’flo’ flag option in a module
A -env_pop or -env_restore option encountered within a module is recalling an option environment in which the state of the flo ﬂag option is diﬀerent. The value of the flo ﬂag is not intended to be changed within a module and doing so indirectly likely will not have the desired eﬀect.
continued processing after failing to open header files may result in incomplete or inaccurate analysis
A suppression option was used to explicitly suppress fatal error 322 . The presence of error 322 typically indicates a conﬁguration issue. Attempting to resolve the issue by suppressing the message is likely to result in additional errors and/or incomplete analysis.

687
warning
body of 'string' is an unparenthesized comma operator
A comma operator appeared unbraced and unparenthesized in a statement following an if, else, while or for clause. For example:

if( n > 0 ) n = 1, 
n = 2;

Thus the comma could be mistaken for a semi-colon and hence be the source of subtle bugs.

If the statement is enclosed in curly braces or if the expression is enclosed in parentheses, the message is not issued.

689
warning
apparent end of C-style comment ignored
The pair of characters ’*/’ was found not within a comment. As an example:

void f( void*/*comment*/ );

This is taken to be the equivalent of:

void f( void* );

That is, an implied blank is inserted between the ’*’ and the ’/’. To avoid this message simply place an explicit blank between the two characters.
Supports CERT C MSC04-C - Use comments consistently and in a readable fashion

691
warning
suspicious use of backslash
The backslash character has been used in a way that may produce unexpected results. Typically this would occur within a macro such as:

#define A b \ // comment

The coder might be thinking that the macro deﬁnition will be continued on to the next line. The standard indicates, however, that the newline will not be dropped in the event of an intervening comment. This should probably be recoded as:

#define A b /* comment */ \

692
warning
decimal character 'string' follows octal escape sequence 'string'
A string was found that contains an ’8’ or ’9’ after an octal escape sequence with no more than two octal digits, e.g.

"\079"

contains two characters: Octal seven (ASCII BEL) followed by ’9’. The casual reader of the code (and perhaps even the programmer) could be fooled into thinking this is a single character. If this is what the programmer intended he can also render this as

"\07" "9"

so that there can be no misunderstanding. On the other hand,

"\1238"

will not raise a message because it is assumed that the programmer knows that octal escape sequences cannot exceed four characters (including the initial backslash).

693
warning
the sequence "detail" represents a NUL character followed by the literal string "detail"
A string was found that looks suspiciously like (but is not) a hexadecimal escape sequence; rather, it is a null character followed by letter "x" followed by some hexadecimal digit, e.g.:

"\0x62"

was found where the programmer probably meant to type "\x62". If you need precisely this sequence you can use:

"\0" "x62"

and this warning will not be issued.
Supports CWE-170 - Improper Null Termination
Supports CWE-463 - Deletion of Data Structure Sentinel

695
warning
inline function symbol declared without storage-class speciﬁer
In C99, the result of a call to a function declared with ’inline’ but not ’static’ or ’extern’ is unspeciﬁed.

Example: Let the following text represent two translation units:

module1.c

void f() { }

module2.c

inline void f() { } 
void g() { f(); }  /* which f() is called? */

The C99 Standard dictates that the above call to f() from g() in module2.c may result in the execution of either f().

The programmer may avoid confusion and improve portability by using the keyword ’static’ in addition to ’inline’. The keyword ’extern’ can also be used along with the ’inline’ to resolve this ambiguity; however, we recommend using ’static’ because, as of this writing, more compilers correctly interpret ’static inline’.
Supports MISRA C 2012 Rule 8.10 - An inline function shall be declared with the static storage class
Supports MISRA C:2023 Rule 8.10 - An inline function shall be declared with the static storage class
Supports MISRA C:2025 Rule 8.10

696
warning
values from 'integer' to 'integer' are out of range for operator 'string'
The variable is being compared (using one of the 6 comparison operations) with some other expression called the comperand. The variable has a value that is out of the range of values of this comperand. For example consider:

void f(unsigned char ch) { 
   int n = 1000; 
   if (ch < n)    // Message 696 
   ... 
}

Here a message 696 will be issued stating that n has a value of 1000 that is out of range because 1000 is not in the set of values that ch can hold (assuming default sizes of scalars).

697
warning
an expression with an integral strong boolean type should be equality-compared only to zero
A quasi-boolean value is being compared (using either != or ==) with a value that is not the literal zero. A quasi-boolean value is any value whose type is a strong boolean type and that could conceivably be something other than zero or one. This is signiﬁcant because in C, all non-zero values are equally true. Example:

/*lint -strong(AJXb, B) */ 
typedef int B; 
#define YES ((B)1) 
#define NO ((B)0) 
 
B f( B a, B b ) { 
   B c = ( a == NO);         /*OK, no Warning here*/ 
   B d = ( a == (b != NO) );  /* Warning 697 for == but not for != */ 
   B e = ( a == YES );       /* Warning 697 here */ 
   return d == c;            /* Warning 697 here */ 
}

Note that if a and b had instead been declared with true boolean types, such as ’bool’ in C++ or ’_Bool’ in C99, this diagnostic would not have been issued.
Supports CERT C EXP20-C - Perform explicit tests to determine success, true and false, and equality

698
warning
in-place realloc of symbol could cause a memory leak
A statement of the form:

v = realloc( v, ... );

has been detected. Note the repeated use of the same variable. The problem is that realloc can fail to allocate the necessary storage. In so doing it will return NULL. But then the original value of v is overwritten resulting in a memory leak.
Supports MISRA C 2012 Rule 22.1 - All resources obtained dynamically by means of Standard Library functions shall be explicitly released
Supports MISRA C:2023 Rule 22.1 - All resources obtained dynamically by means of Standard Library functions shall be explicitly released
Supports MISRA C:2025 Rule 22.1

701
info
shift left of signed quantity (type)
Shifts are normally accomplished on unsigned operands. This message is only emitted if sizeof(type) <= sizeof(int).
Supports CERT C INT02-C - Understand integer conversion rules
Supports CWE-192 - Integer Coercion Error
Supports CWE-197 - Numeric Truncation Error

702
info
shift right of signed quantity (type)
Shifts are normally accomplished on unsigned operands. Shifting an int right is machine dependent (sign ﬁll vs. zero ﬁll). This message is only emitted if sizeof(type) <= sizeof(int).
Supports CERT C INT02-C - Understand integer conversion rules
Supports CWE-192 - Integer Coercion Error
Supports CWE-197 - Numeric Truncation Error

703
info
shift left of signed quantity (type)
Shifts are normally accomplished on unsigned operands. This message is only emitted if sizeof(type) > sizeof(int).

704
info
shift right of signed quantity (type)
Shifts are normally accomplished on unsigned operands. Shifting a long to the right is machine dependent (sign ﬁll vs. zero ﬁll). This message is only emitted if sizeof(type) > sizeof(int).

705
info
format 'string' speciﬁes type type which is nominally inconsistent with argument no. integer of string type
The argument corresponding to a conversion speciﬁer in a printf/scanf style function was not of the correct type but was the same size as the expected integer type. The format, expected argument type, argument number, and the type of the data argument provided are reported. Argument counts begin at 1 and include ﬁle, string, and data arguments. For example:

extern char * buffer; 
sprintf(buffer, "%u", 371);

will elicit the message:

format '%u' specifies type 'unsigned int' which is nominally 
inconsistent with argument no. 3 of type 'int'

In addition to diﬀerences in signedness of same-sized integers, two types that are the same size and signedness but distinct types are also reported by this message. For example, if int and long are the same size, passing a long argument to %d will elicit this message.
Supports CERT C INT00-C - Understand the data model used by your implementation(s)
Supports CERT C FIO47-C - Use valid format strings
Supports CWE-134 - Use of Externally-Controlled Format String
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports CWE-686 - Function Call With Incorrect Argument Type
Supports CWE-843 - Access of Resource Using Incompatible Type (‘Type Confusion’)
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

706
info
format 'string' speciﬁes type type whose pointee type is nominally inconsistent with argument no. integer of string type
The argument corresponding to a conversion speciﬁer in a printf/scanf style function was not of the correct type but was a pointer to a type that is the same size as the expected pointee integer type. The format, expected argument type, argument number, and the type of the data argument provided are reported. Argument counts begin at 1 and include ﬁle, string, and data arguments. For example:

int j; 
scanf("%u", &j);

will result in the message:

format '%u' specifies type 'unsigned int *' whose pointee type 
is nominally inconsistent with argument no. 2 of type 'int *'

In addition to diﬀerences in signedness of same-sized integers, pointers to types that are the same size and signedness but distinct types are also reported by this message. For example, if int and long are the same size, passing a long * argument to %d will elicit this message.
Supports CERT C INT00-C - Understand the data model used by your implementation(s)
Supports CERT C FIO47-C - Use valid format strings
Supports CWE-134 - Use of Externally-Controlled Format String
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports CWE-686 - Function Call With Incorrect Argument Type
Supports CWE-843 - Access of Resource Using Incompatible Type (‘Type Confusion’)
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

707
info
mixing narrow and wide/Unicode string literals in concatenation
The following is an example of a mixing of narrow and wide string literals.

const wchar_t *s = "abc" L"def";

The concatenation of narrow and wide string literals results in undeﬁned behavior for C90 and C++2003. If your compiler supports such combinations or you use a C/C++ dialect that supports such, you may either suppress this message or consider making the concatenands match.
Supports CERT C STR10-C - Do not concatenate diﬀerent type of string literals
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3
Supports MISRA C++:2008 Rule 2-13-5 - Narrow and wide string literals shall not be concatenated.
Supports MISRA C++:2023 Rule 5.13.7 - String literals with diﬀerent encoding preﬁxes shall not be concatenated

708
info
union initialization
A union was initialized without explicitly specifying which member to initialize. While the C and C++ standards state that the ﬁrst member of the union is initialized in such cases, other members may not have fully initialized values. For example:

union U { int a; int * p; }; 
U u1 = { 0 };

On a system where int is 4 bytes and pointers are 8 bytes, the int member of u1 is initialized to 0 but the bytes of p that do not overlap with a are not initialized, which may come as a surprise, especially since the behavior is dependent on the order in which the union members are declared and on the size of pointers relative to ints.

709
info
no intervening module since the last '-pch' option
Two -pch options were seen without an intervening module. This is suspicious because the ﬁrst -pch option has no eﬀect in such a case as only one PCH ﬁle can be used per module.

712
info
implicit conversion (context) from type to type
An assignment (or implied assignment, see context) is being made from a source type (the ﬁrst type) to a destination type (the second type) and the ﬁrst type is larger than the second type. A cast will suppress this message.

713
info
implicit conversion (context) from type to type
An assignment (or implied assignment, see context) is being made from an unsigned quantity to a signed quantity, that will result in the possible loss of one bit of integral precision, such as converting from unsigned int to int. A cast will suppress the message.

714
info
external symbol symbol was deﬁned but not referenced
The named external variable or external function was deﬁned but not referenced. This message is not issued for library symbols and is suppressed for unit checkout (-unit_check option).
Supports AUTOSAR17 Rule M0-1-3
Supports AUTOSAR17 Rule M0-1-10
Supports AUTOSAR19 Rule M0-1-3
Supports AUTOSAR19 Rule M0-1-10
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code
Supports MISRA C 2012 AMD4 Rule 2.8 - A project should not contain unused object deﬁnitions
Supports MISRA C:2023 Rule 2.8 - A project should not contain unused object deﬁnitions
Supports MISRA C:2025 Rule 2.8
Supports MISRA C++:2008 Rule 0-1-3 - A project shall not contain unused variables.
Supports MISRA C++:2008 Rule 0-1-10 - Every deﬁned function shall be called at least once.

715
info
named parameter symbol of 'virtual/non-virtual' function symbol not subsequently referenced
The named formal parameter was not referenced.
Supports AUTOSAR17 Rule M0-1-11
Supports AUTOSAR19 Rule A0-1-4
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CERT C MSC13-C - Detect and remove unused values
Supports CWE-561 - Dead Code
Supports MISRA C 2012 Rule 2.7 - A function should not contain unused parameters
Supports MISRA C:2023 Rule 2.7 - A function should not contain unused parameters
Supports MISRA C:2025 Rule 2.7
Supports MISRA C++:2008 Rule 0-1-11 - There shall be no unused parameters (named or unnamed) in non-virtual functions.
Supports MISRA C++:2008 Rule 0-1-12 - There shall be no unused parameters (named or unnamed) in the set of parameters for a virtual function and all the functions that override it.
Supports MISRA C++:2023 Rule 0.2.2 - A named function parameter shall be used at least once

716
info
inﬁnite loop via while
A construct of the form while (1) or while (true) was found. While this represents a constant value in a context expecting a Boolean — typically reported by message 506 — it may reﬂect a programming policy to indicate an intentional inﬁnite loop. It is therefore given a separate number and has been placed in the informational category. Some may prefer to denote such loops using for (;;) instead.

717
info
monocarpic do-while used to group statements
A construct of the form do … while (0) or do … while (false) was found. While this represents a constant value in a context expecting a Boolean — typically reported by message 506 — it is probably a deliberate attempt on the part of the programmer to encapsulate a sequence of statements into a single statement. It is therefore given a separate number and has been placed in the informational category [?, Section 19.7].

718
info
function symbol undeclared, assumed to return int
A function was referenced without having been declared or deﬁned within the current module. Such implicit function declarations were removed in C99 although some compilers still allow them. These implicit function declarations were never allowed in C++ and referencing an undeclared function in a C++ module will instead result in an error. Note that by adding a declaration to another module, you will not suppress this message. It can only be suppressed by placing a declaration within the module being processed.
Supports CERT C DCL07-C - Include the appropriate type information in function declarators
Supports CERT C DCL31-C - Declare identiﬁers before using them
Supports MISRA C 2004 Rule 8.1 - Functions shall have prototype declarations and the prototype shall be visible at both the function deﬁnition and call.
Supports MISRA C 2012 Rule 17.3 - A function shall not be declared implicitly
Supports MISRA C:2023 Rule 17.3 - A function shall not be declared implicitly
Supports MISRA C:2025 Rule 17.3

719
info
data argument integer not used by format string
The number of data arguments passed to a printf/scanf style function was more than what is speciﬁed in the format. This message is similar to Warning 558 , which alerts users to situations in which there were too few arguments for the format. It receives a lighter Informational classiﬁcation because the additional arguments are simply ignored whereas passing too few arguments results in undeﬁned behavior.
Supports CERT C DCL10-C - Maintain the contract between the writer and caller of variadic functions
Supports CERT C FIO47-C - Use valid format strings
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-134 - Use of Externally-Controlled Format String
Supports CWE-561 - Dead Code
Supports CWE-628 - Function Call with Incorrectly Speciﬁed Arguments
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports CWE-686 - Function Call With Incorrect Argument Type
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

720
info
boolean test of assignment
An assignment was found in a context that requires a Boolean (such as the condition of an if or while statement). This may be legitimate or it could have resulted from a mistaken use of = for ==. If the assignment was intentional, placing additional parenthesis around the assignment (e.g. if ((a = b))) will suppress this message.
Supports AUTOSAR17 Rule M6-2-1
Supports AUTOSAR19 Rule M6-2-1
Supports CERT C EXP45-C - Do not perform assignments in selection statements
Supports CWE-480 - Use of Incorrect Operator
Supports CWE-481 - Assigning instead of Comparing
Supports CWE-783 - Operator Precedence Logic Error
Supports MISRA C 2004 Rule 13.1 - Assignment operators shall not be used in expressions that yield a Boolean value.
Supports MISRA C 2012 Rule 13.4 - The result of an assignment operator should not be used
Supports MISRA C:2023 Rule 13.4 - The result of an assignment operator should not be used
Supports MISRA C:2025 Rule 13.4
Supports MISRA C++:2008 Rule 6-2-1 - Assignment operators shall not be used in sub-expressions.
Supports MISRA C++:2023 Rule 8.18.2 - The result of an assignment operator should not be used

721
info
if statement has empty body
A semi-colon was found immediately to the right of a right parenthesis in a construct of the form if(e);. As such it may be overlooked or confused with the use of semi-colons to terminate statements. The message will be inhibited if the ’;’ is separated by at least one blank from the ’)’. Better, place it on a separate line. See also message 548 .
Supports CERT C EXP15-C - Do not place a semicolon on the same line as an if, for, or while statement

722
info
'context' statement has empty body
A semi-colon was found immediately to the right of a right parenthesis in a construct of the form while(e); or for(e;e;e); As such it may be overlooked or confused with the use of semi-colons to terminate statements. The message will be inhibited if the ’;’ is separated by at least one blank from the ’)’. Better, place it on a separate line.
Supports CERT C EXP15-C - Do not place a semicolon on the same line as an if, for, or while statement

723
info
macro deﬁnition starting with = is suspicious
A preprocessor deﬁnition began with an = sign. For example:

#define LIMIT = 50

Was this intentional? Or was the programmer thinking of assignment when he wrote this?

725
info
unexpected lack of indentation
The current line was found to be aligned with, rather than indented with respect to, the indicated line. The indicated line corresponds to a clause introducing a control structure and statements within its scope are expected to be indented with respect to it. If tabs within your program are other than 8 blanks you should use the -t option (See Section 17.4 Indentation Checking ).
Supports CWE-483 - Incorrect Block Delimitation

726
info
extraneous comma ignored at end of enumerator list after enumerator symbol
A comma followed by a right-brace within an enumeration is not a valid ANSI/ISO construct. The comma is ignored. This message is only emitted in C90 and C++03 modes as later versions allow this construct.

727
info
static local symbol symbol not explicitly initialized
The named static variable (local to a function) was not explicitly initialized before use. The following remarks apply to messages 728 and 729 as well as 727. By no explicit initialization we mean that there was no initializer present in the deﬁnition of the object, no direct assignment to the object (or any of its elements or members), and no address operator applied to the object or, if the address of the object was taken, it was assigned to a pointer to const. Arrays are also considered to be explicitly initialized if the result of array to pointer decay is assigned to a non-const pointer.

These messages do not necessarily signal errors since the implicit initialization for static variables is 0. However, the messages are helpful in indicating those variables that you had forgotten to initialize to a value. To extract the maximum beneﬁt from the messages we suggest that you employ an explicit initializer for those variables that you want to initialize to 0. For example:

static int n = 0;

For variables that will be initialized dynamically, do not use an explicit initializer as in:

static int m;

This message will be given for any array, class, struct or union if no member or element has been assigned a value. The fde ﬂag controls how initialization using a default constructor is interpreted in C++.

728
info
ﬁle scope static variable symbol not explicitly initialized
The named intra-module variable (static variable with ﬁle scope) was not explicitly initialized. See the comments on message 727 for more details.

729
info
external variable symbol not explicitly initialized
The named inter-module variable (external variable) was not explicitly initialized. See the comments on message 727 for more details. This message is not issued for library symbols and suppressed for unit checkout (-unit_check ) and will not report C++ classes.

730
info
boolean used as argument integer to function symbol
A Boolean was used as an argument to a function. Was this intended? Or was the programmer confused by a particularly complex conditional statement? Experienced C programmers often suppress this message. This message is given only if the associated parameter is not declared bool.

731
info
boolean argument(s) to equality-operator
A Boolean operator was used as an argument to == or !=. For example:

if( (a > b) == (c > d) )       ...

tests to see if the inequalities are of the same value. This could be an error as it is an unusual use of a Boolean (see Warnings 503 and 514 ) but it may also be deliberate since this is the only way to eﬃciently achieve equivalence or exclusive or. Because of this possible use, the construct is given a relatively mild ’informational’ classiﬁcation. If the Boolean argument is cast to some type, this message is not given. Additionally, this message is not necessarily given just because one of the arguments to == or != is a Boolean type but only if at least one of the arguments is expressed using a Boolean operator. For example, if e and f are of type bool, the clause:

if( e == f ) ...

will not prompt this message. However,

if( e == !f ) ...

will.
Supports CERT C EXP13-C - Treat relational and equality operators as if they were nonassociative

732
info
loss of sign (context) (type to type)
An assignment (or implied assignment, see context) is made from a signed quantity to an unsigned quantity. Also, it could not be determined that the signed quantity had no sign. For example:

u = n;    /* Info 732 */ 
u = 4;    /*  OK     */

where u is unsigned and n is not, warrants a message only for the ﬁrst assignment, even though the constant 4 is nominally a signed int.

Make sure that this is not an error (that the assigned value is never negative) and then use a cast (to unsigned) to remove the message.
Supports CERT C INT02-C - Understand integer conversion rules
Supports CWE-192 - Integer Coercion Error
Supports CWE-195 - Signed to Unsigned Conversion Error
Supports CWE-197 - Numeric Truncation Error
Supports CWE-562 - Return of Stack Variable Address
Supports CWE-681 - Incorrect Conversion between Numeric Types
Supports CWE-704 - Incorrect Type Conversion or Cast

733
info
likely assigning address of local symbol to outer scope pointer symbol
The address of an auto variable is valid only within the block in which the variable is declared. An address to such a variable has been assigned to a variable that has a longer life expectancy. There is an inherent danger in doing this.
Supports CERT C DCL30-C - Declare objects with appropriate storage durations
Supports CWE-562 - Return of Stack Variable Address
Supports MISRA C 2004 Rule 17.6 - The address of an object with automatic storage shall not be assigned to another object that may persist after the ﬁrst object has ceased to exist.
Supports MISRA C 2012 Rule 18.6 - The address of an object with automatic storage shall not be copied to another object that persists after the ﬁrst object has ceased to exist
Supports MISRA C:2023 Rule 18.6 - The address of an object with automatic storage shall not be copied to another object that persists after the ﬁrst object has ceased to exist
Supports MISRA C:2025 Rule 18.6
Supports MISRA C++:2023 Rule 6.8.3 - An assignment operator shall not assign the address of an object with automatic storage duration to an object with a greater lifetime

734
info
loss of precision (context) from number bits to number bits
An assignment is being made into an object smaller than an int. The information being assigned is derived from another object or combination of objects in such a way that information could potentially be lost. The number of bits given does not count the sign bit. For example if ch is a char and n is an int then:

ch = n;

will trigger this message whereas:

ch = n & 1;

will not. To suppress the message a cast can be made as in:

ch = (char) n;

You may receive notices involving multiplication and shift operators with subinteger variables. For example:

ch = ch << 2; 
ch = ch * ch;

where, for example, ch is an unsigned char. These can be suppressed by using the ﬂag +fpm (precision of an operator is bound by the maximum of its operands).
Supports CERT C INT02-C - Understand integer conversion rules
Supports CWE-192 - Integer Coercion Error
Supports CWE-197 - Numeric Truncation Error

735
info
implicit conversion (context) from type to type
An assignment (or implied assignment, see context) is made from a long double to a double. Using a cast will suppress the message. The number of bits includes the sign bit.
Supports CERT C FLP34-C - Ensure that ﬂoating-point conversions are within range of the new type
Supports CWE-197 - Numeric Truncation Error
Supports CWE-681 - Incorrect Conversion between Numeric Types

736
info
loss of precision (context) from number bits to number bits
An assignment (or implied assignment, see context) is being made to a float from a value or combination of values that appear to have higher precision than a float. You may suppress this message by using a cast. The number of bits includes the sign bit.
Supports CERT C FLP03-C - Detect and handle ﬂoating-point errors
Supports CERT C FLP34-C - Ensure that ﬂoating-point conversions are within range of the new type
Supports CWE-197 - Numeric Truncation Error
Supports CWE-369 - Divide By Zero
Supports CWE-681 - Incorrect Conversion between Numeric Types

737
info
loss of sign in promotion from type to type
An unsigned quantity was joined with a signed quantity in a binary operator (or 2nd and 3rd arguments to the conditional operator) and the signed quantity is implicitly converted to unsigned. The message will not be given if the signed quantity is an unsigned constant, a Boolean, or an expression involving bit manipulation. For example,

u & ~0xFF

where u is unsigned does not draw the message even though the operand on the right is technically a signed integer constant. It looks enough like an unsigned to warrant not giving the message.

This mixed mode operation could also draw Warnings 573 or 574 depending upon the operator involved.

You may suppress the message with a cast but you should ﬁrst determine whether the signed value could ever be negative or whether the unsigned value can ﬁt within the constraints of a signed quantity.
Supports CERT C INT02-C - Understand integer conversion rules
Supports CERT C API09-C - Compatible values should have the same type
Supports CWE-192 - Integer Coercion Error
Supports CWE-195 - Signed to Unsigned Conversion Error
Supports CWE-197 - Numeric Truncation Error

738
info
address of static local symbol symbol not explicitly initialized before passed to a function
The named static local variable was not initialized before being passed to a function whose corresponding parameter is declared as pointer to const. Is this an error or is the programmer relying on the default initialization of 0 for all static items? By employing an explicit initializer you will suppress this message. See also message numbers 727 and 603 .
Supports CWE-456 - Missing Initialization of a Variable

739
info
trigraph sequence 'string' in string literal
The indicated Trigraph (three-character) sequence was found within a string. This trigraph reduces to a single character according to the ANSI/ISO standards. This represents a "Quiet Change" from the past where the sequence was not treated as exceptional. If you had no intention of mapping these characters into a single character you may precede the initial ’?’ with a backslash. If you are aware of the convention and you intend that the Trigraph be converted you should suppress this informational message.
Supports AUTOSAR17 Rule A2-5-1
Supports AUTOSAR19 Rule A2-5-1
Supports MISRA C 2004 Rule 4.2 - Trigraphs shall not be used.
Supports MISRA C 2012 Rule 4.2 - Trigraphs should not be used
Supports MISRA C:2023 Rule 4.2 - Trigraphs should not be used
Supports MISRA C:2025 Rule 4.2
Supports MISRA C++:2008 Rule 2-3-1 - Trigraphs shall not be used.

742
info
multi-character character constant
A character constant was found that contained multiple characters, e.g., ’ab’. This is legal C but the numeric value of the constant is implementation deﬁned. It may be safe to suppress this message because, if more characters are provided than what can ﬁt in an int, message number 25 is given.

743
info
negative character constant
A character constant was speciﬁed whose value is some negative integer. For example, on machines where a byte is 8 bits, the character constant ’\xFF’ is ﬂagged because its value (according to the ANSI/ISO standard) is -1 (its type is int). Note that its value is not 0xFF.

744
info
switch statement has no default
A switch statement has no section labeled default. Was this an oversight? It is standard practice in many programming groups to always have a default: case. This can lead to better (and earlier) error detection. One way to suppress this message is by introducing a vacuous default break; statement. If you think this adds too much overhead to your program, think again. In all cases tested so far, the introduction of this statement added absolutely nothing to the overall length of code. If you accompany the vacuous statement with a suitable comment, your code will at least be more readable.

This message is not given if the control expression is an enumerated type. In this case, all enumerated constants are expected to be represented by case statements, else 787 will be issued.
Supports AUTOSAR17 Rule M6-4-6
Supports AUTOSAR19 Rule M6-4-6
Supports CERT C MSC01-C - Strive for logical completeness
Supports CWE-478 - Missing Default Case in Multiple Condition Expression
Supports MISRA C 2012 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C 2012 Rule 16.4 - Every switch statement shall have a default label
Supports MISRA C:2023 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C:2023 Rule 16.4 - Every switch statement shall have a default label
Supports MISRA C:2025 Rule 16.1
Supports MISRA C:2025 Rule 16.4
Supports MISRA C++:2008 Rule 6-4-6 - The ﬁnal clause of a switch statement shall be the default-clause.

746
info
call to function symbol not made in the presence of a prototype
A call to a function is not made in the presence of a prototype. This does not mean that PC-lint Plus is unaware of any prototype; it means that a prototype is not in a position where a compiler will see it. If you have not adopted a strict prototyping convention you will want to suppress this message with -e746.
Supports CERT C DCL07-C - Include the appropriate type information in function declarators
Supports CERT C DCL31-C - Declare identiﬁers before using them
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports MISRA C 2004 Rule 8.1 - Functions shall have prototype declarations and the prototype shall be visible at both the function deﬁnition and call.

749
info
local enumeration constant symbol not referenced
A member (name provided as symbol) of an enum was deﬁned in a module but was not otherwise used within that module. A ’local’ member is one that is not deﬁned in a header ﬁle. Compare with messages 754 and 769 .
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code

750
info
local macro 'string' not referenced
A ’local’ macro is one that is not deﬁned in a header ﬁle. The macro is not referenced throughout the module in which it is deﬁned.
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code
Supports MISRA C 2012 Rule 2.5 - A project should not contain unused macro declarations
Supports MISRA C:2023 Rule 2.5 - A project should not contain unused macro declarations
Supports MISRA C:2025 Rule 2.5

751
info
local typedef symbol not referenced
A ’local’ typedef symbol is one that is not deﬁned in any header ﬁle. It may have ﬁle scope or block scope but it was not used through its scope.
Supports AUTOSAR17 Rule M0-1-5
Supports AUTOSAR19 Rule A0-1-6
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code
Supports MISRA C 2012 Rule 2.3 - A project should not contain unused type declarations
Supports MISRA C:2023 Rule 2.3 - A project should not contain unused type declarations
Supports MISRA C:2025 Rule 2.3
Supports MISRA C++:2008 Rule 0-1-5 - A project shall not contain unused type declarations.

752
info
local declarator symbol not referenced
A ’local’ declarator symbol is one declared in a declaration appearing in the module ﬁle itself as opposed to a header ﬁle. The symbol may have ﬁle scope or may have block scope. But it wasn’t referenced.
Supports AUTOSAR17 Rule M0-1-3
Supports AUTOSAR19 Rule M0-1-3
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code
Supports MISRA C++:2008 Rule 0-1-3 - A project shall not contain unused variables.

753
info
local string symbol not referenced
string is one of struct, class, union, or enum and symbol is the name of the tag. A ’local’ tag is one not deﬁned in a header ﬁle. Since its deﬁnition appeared, why was it not used? Use of a tag is implied by the use of any of its members.
Supports AUTOSAR17 Rule M0-1-5
Supports AUTOSAR19 Rule A0-1-6
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code
Supports MISRA C 2012 Rule 2.4 - A project should not contain unused tag declarations
Supports MISRA C:2023 Rule 2.4 - A project should not contain unused tag declarations
Supports MISRA C:2025 Rule 2.4
Supports MISRA C++:2008 Rule 0-1-5 - A project shall not contain unused type declarations.

754
info
local string member symbol not referenced
A member (name provided as symbol) of a struct, class, or union (as indicated in string) was deﬁned in a module but was not otherwise used within that module. A ’local’ member is one that is not deﬁned in a header ﬁle. See message 768 .
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code

755
info
global macro 'string' not referenced
A ’global’ macro is one deﬁned in a header ﬁle. The macro is not used in any of the modules comprising the program. This message is suppressed for unit checkout (-unit_check option).
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code
Supports MISRA C 2012 Rule 2.5 - A project should not contain unused macro declarations
Supports MISRA C:2023 Rule 2.5 - A project should not contain unused macro declarations
Supports MISRA C:2025 Rule 2.5

756
info
global typedef symbol not referenced
This message is given for a typedef symbol declared in a non-library header ﬁle. The symbol is not used in any of the modules comprising a program. This message is suppressed for unit checkout (-unit_check option).
Supports AUTOSAR17 Rule M0-1-5
Supports AUTOSAR19 Rule A0-1-6
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code
Supports MISRA C 2012 Rule 2.3 - A project should not contain unused type declarations
Supports MISRA C:2023 Rule 2.3 - A project should not contain unused type declarations
Supports MISRA C:2025 Rule 2.3
Supports MISRA C++:2008 Rule 0-1-5 - A project shall not contain unused type declarations.

757
info
global declarator symbol not referenced
A ’global’ declarator is one deﬁned in a header ﬁle. This message is given for objects declared in non-library header ﬁles that have not been used in any module comprising the program being checked. The message is suppressed for unit checkout (-unit_check ).
Supports AUTOSAR17 Rule M0-1-3
Supports AUTOSAR19 Rule M0-1-3
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code
Supports MISRA C++:2008 Rule 0-1-3 - A project shall not contain unused variables.

758
info
global string symbol not referenced
A ’global’ tag is one that is deﬁned in a header ﬁle. This message is given for struct, union and enum tags that have been deﬁned in non-library header ﬁles and that have not been used in any module comprising the program. The message is suppressed for unit checkout (-unit_check ).
Supports AUTOSAR17 Rule M0-1-5
Supports AUTOSAR19 Rule A0-1-6
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code
Supports MISRA C++:2008 Rule 0-1-5 - A project shall not contain unused type declarations.

759
info
header declaration for symbol symbol could be moved from header to module
This message is given for declarations of non-library symbols that are not referenced outside the deﬁning module. Hence, it can be moved inside the module and thereby ’lighten the load’ on all modules using the header. This message is suppressed for unit checkout (-unit_check option).
Supports MISRA C++:2008 Rule 3-3-1 - Objects or functions with external linkage shall be declared in a header ﬁle.

760
info
redundant macro name deﬁned identically
The given macro was deﬁned earlier in the same way and is hence redundant. If a macro is deﬁned identically across modules, then message 962 will be reported.
Supports MISRA C 2012 Rule 5.4 - Macro identiﬁers shall be distinct
Supports MISRA C:2023 Rule 5.4 - Macro identiﬁers shall be distinct
Supports MISRA C:2025 Rule 5.4

761
info
redundant typedef name
A typedef symbol has been declared earlier and is redundant. Although the declarations are consistent you should probably remove the second.

764
info
switch with no cases
A switch statement has been found that does not have a case statement associated with it (it may or may not have a default statement). This is normally a useless construct.
Supports MISRA C 2004 Rule 15.5 - Every switch statement shall have at least one case clause.
Supports MISRA C 2012 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C 2012 Rule 16.6 - Every switch statement shall have at least two switch-clauses
Supports MISRA C:2023 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C:2023 Rule 16.6 - Every switch statement shall have at least two switch-clauses
Supports MISRA C:2025 Rule 16.1
Supports MISRA C:2025 Rule 16.6
Supports MISRA C++:2008 Rule 6-4-8 - Every switch statement shall have at least one case-clause.

765
info
external symbol symbol could be made static
An external symbol was referenced in only one module. It was not declared static. Some programmers like to make static every symbol they can, because this lightens the load on the linker. It also represents good documentation. This message is not issued for library symbols and is suppressed for unit checkout (-unit_check option).
Supports CERT C DCL15-C - Declare ﬁle-scope objects or functions that do not need external linkage as static
Supports CERT C DCL19-C - Minimize the scope of variables and functions
Supports MISRA C 2004 Rule 8.10 - All declarations and deﬁnitions of objects or functions at ﬁle scope shall have internal linkage unless external linkage is required.
Supports MISRA C 2012 Rule 8.7 - Functions and objects should not be deﬁned with external linkage if they are referenced in only one translation unit
Supports MISRA C:2023 Rule 8.7 - Functions and objects should not be deﬁned with external linkage if they are referenced in only one translation unit
Supports MISRA C:2025 Rule 8.7
Supports MISRA C++:2008 Rule 3-3-1 - Objects or functions with external linkage shall be declared in a header ﬁle.

767
info
macro 'macro' deﬁned diﬀerently in another module
The same macro was deﬁned in another module with an inconsistent deﬁnition. For example:

FileA.c

#define X(A,B) A + B

FileB.c

#define X(A,B) A * B  // info 767

If a macro is deﬁned inconsistently in the same module, then message 547 will be reported.
Supports MISRA C 2012 Rule 5.4 - Macro identiﬁers shall be distinct
Supports MISRA C:2023 Rule 5.4 - Macro identiﬁers shall be distinct
Supports MISRA C:2025 Rule 5.4

768
info
global structure member symbol not referenced
A member (name provided as symbol) of a struct or union appeared in a non-library header ﬁle but was not used in any module comprising the program. This message is suppressed for unit checkout. Since a struct may be replicated in storage, ﬁnding an unused member can pay handsome storage dividends. However, many structures merely reﬂect an agreed upon convention for accessing storage and for any one program, many members are unused. In this case, receiving this message can be a nuisance. One convenient way to avoid unwanted messages (other than the usual -e and -esym ) is to always place such structures in library header ﬁles. Alternatively, you can place the struct within a ++flb ... –flb sandwich to force it to be considered library.
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code

769
info
global enumeration constant symbol not referenced
A member (name provided as symbol) of an enum appeared in a non-library header ﬁle but was not used in any module comprising the program. This message is suppressed for unit checkout. There are reasons why a programmer may occasionally want to retain an unused enum and for this reason this message is distinguished from 768 (unused member). See message 768 for ways of selectively suppressing this message.
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code

770
info
tag symbol deﬁned identically at location
The struct, union, or enum tag symbol was deﬁned identically in diﬀerent locations (usually two diﬀerent ﬁles). This is not an error but it is not necessarily good programming practice either. It is better to place common deﬁnitions of this kind in a header ﬁle where they can be shared among several modules. If you do this, you will not get this message. Note that if the tag is deﬁned diﬀerently in diﬀerent scopes, you will receive warning 631 rather than this message. This message is suppressed for unit checkout (-unit_check option).

773
info
expression-like macro 'string' not parenthesized
A macro that appeared to be an expression contained unparenthesized binary operators and therefore may result in unexpected associations when used with other operators. For example,

#define A B + 1

may be used later in the context:

f( A * 2 );

with the surprising result that B+2 gets passed to f and not the (B+1)*2. Corrective action is to deﬁne A as:

#define A (B + 1)

Highest precedence binary operators are not reported upon. Thus:

#define A s.x

does not elicit this message because this case does not seem to represent a problem. Also, unparenthesized unary operators (including casts) do not generate this message. [?, Section 19.5]
Supports CERT C PRE02-C - Macro replacement lists should be parenthesized

774
info
boolean condition for 'detail' always evaluates to 'detail'
The indicated clause (detail is one of if, while or for (2nd expression)) has an argument that appears to always evaluate to either ’true’ or ’false’ (as indicated in the message). Information is gleaned from a variety of sources including prior assignment statements and initializers. Compare this with message 506 , which is based on testing constants or combinations of constants. Also compare with the Elective Note 944 , which can sometimes provide more detailed information. See Chapter 8 Value Tracking .
Supports AUTOSAR17 Rule M0-1-1
Supports AUTOSAR17 Rule M0-1-2
Supports AUTOSAR17 Rule M0-1-9
Supports AUTOSAR19 Rule M0-1-1
Supports AUTOSAR19 Rule M0-1-2
Supports AUTOSAR19 Rule M0-1-9
Supports CERT C MSC12-C - Detect and remove code that has no eﬀect or is never executed
Supports CWE-561 - Dead Code
Supports CWE-570 - Expression is Always False
Supports CWE-571 - Expression is Always True
Supports MISRA C 2004 Rule 13.7 - Boolean operations whose results are invariant shall not be permitted.
Supports MISRA C 2012 Rule 2.2 - A project shall not contain dead code
Supports MISRA C 2012 Rule 14.3 - Controlling expressions shall not be invariant
Supports MISRA C:2023 Rule 2.2 - A project shall not contain dead code
Supports MISRA C:2023 Rule 14.3 - Controlling expressions shall not be invariant
Supports MISRA C:2025 Rule 2.2
Supports MISRA C:2025 Rule 14.3
Supports MISRA C++:2008 Rule 0-1-1 - A project shall not contain unreachable code.
Supports MISRA C++:2008 Rule 0-1-2 - A project shall not contain infeasible paths.
Supports MISRA C++:2008 Rule 0-1-9 - There shall be no dead code.
Supports MISRA C++:2023 Rule 0.0.2 - Controlling expressions should not be invariant

775
info
nonnegative quantity cannot be less than zero
A non-negative quantity is being compared for being <=0. This is a little suspicious since a non-negative quantity can be equal to 0 but never less than 0. The non-negative quantity may be of type unsigned or may have been promoted from an unsigned type or may have been judged not to have a sign by virtue of it having been AND’ed with a quantity known not to have a sign bit, an enum that may not be negative, etc. See also Warning 568 .

776
info
possible truncation of addition
An int expression (signed or unsigned) involving addition or subtraction is converted to long implicitly or explicitly. Moreover, the precision of a long is greater than that of int. If an overﬂow occurred, information would be lost. Either cast one of the operands to some form of long or cast the result to some form of int.

See Warning 647 for a further description and an example of this kind of error. See also messages 790 and 942 .
Supports CERT C INT08-C - Verify that all integer values are in range
Supports CWE-681 - Incorrect Conversion between Numeric Types

777
info
testing ﬂoating point values for equality
This message is issued when the operands of operators == and != are some form of ﬂoating type (float, double, or long double). Testing for equality between two ﬂoating point quantities is suspect because of round-oﬀ error and the lack of perfect representation of fractions. If your numerical algorithm calls for such testing turn the message oﬀ. The message is suppressed when one of the operands can be represented exactly, such as 0 or 13.5.
Supports AUTOSAR17 Rule M6-2-2
Supports AUTOSAR19 Rule M6-2-2
Supports CERT C FLP00-C - Understand the limitations of ﬂoating-point numbers
Supports CERT C FLP02-C - Avoid using ﬂoating-point numbers when precise computation is needed
Supports MISRA C 2004 Rule 13.3 - Floating-point expressions shall not be tested for equality or inequality.
Supports MISRA C++:2008 Rule 6-2-2 - Floating-point expressions shall not be directly or indirectly tested for equality or inequality.

778
info
constant expression evaluates to 0 in 'unary/binary' operation 'operator'
A constant expression involving addition, subtraction, multiplication, shifting, or negation resulted in a 0. This could be a purposeful computation but could also have been unintended. If this is intentional, suppress the message. If one of the operands is 0, Elective Note 941 may be issued rather than a 778 .

779
info
string constant in comparison operator 'operator'
A string constant appeared as an argument to a comparison operator. For example:

if( s == "abc" ) ...

This is usually an error. Did the programmer intend to use strcmp? It certainly looks suspicious. At the very least, any such comparison is bound to be machine-dependent. If you cast the string constant, the message is suppressed.
Supports CWE-597 - Use of Wrong Operator in String Comparison

783
info
line does not end with a newline
This message is issued when an input line is not terminated by a new-line or when a NUL character appears within an input line. If your editor is in the habit of not appending new-lines onto the end of the last line of the ﬁle then suppress this message. Otherwise, examine the ﬁle for NUL characters and eliminate them.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

784
info
nul character truncated from string
During initialization of an array with a string constant there was not enough room to hold the trailing NUL character. For example:

char a[3] = "abc";

would evoke such a message. This may not be an error since the easiest way to do this initialization is in the manner indicated. It is more convenient than:

char a[3] = { 'a', 'b', 'c' };

On the other hand, if it really is an error it may be especially diﬃcult to ﬁnd.
Supports CERT C STR11-C - Do not specify the bound of a character array initialized with a string literal
Supports CWE-170 - Improper Null Termination
Supports CWE-464 - Addition of Data Structure Sentinel

785
info
too few initializers for aggregate of type type in initialization of symbol
The number of initializers in a brace-enclosed initializer was less than the number of items in the aggregate. Default initialization is taken. An exception is made with the initializer {0}. This is given a separate message number in the Elective Note category (943 ). It is normally considered to be simply a stylized way of initializing all members to 0. See also 9068 .

786
info
string concatenation within initializer
Although it is perfectly ’legal’ to concatenate string constants within an initializer, this is a frequent source of error. Consider:

char *s[] = { "abc" "def" };

Did the programmer intend to have an array of two strings but forget the comma separator? Or was a single string intended?

787
info
enum constant symbol not used within switch
A switch expression is an enumerated type and at least one of the enumerated constants was not present as a case label. Moreover, no default case was provided.
Supports AUTOSAR17 Rule M6-4-6
Supports AUTOSAR19 Rule M6-4-6
Supports CERT C MSC01-C - Strive for logical completeness
Supports MISRA C++:2008 Rule 6-4-6 - The ﬁnal clause of a switch statement shall be the default-clause.

788
info
enum constant symbol not used within default switch
A switch expression is an enumerated type and at least one of the enumerated constants was not present as a case label. However, unlike Info 787, a default case was provided. This is a mild form of the case reported by Info 787. The user may thus elect to inhibit this mild form while retaining Info 787.

789
info
assigning address of auto variable symbol to static
The address of an auto variable (symbol) is being assigned to a static variable. This is dangerous because the static variable will persist after return from the function in which the auto is declared but the auto will be, in theory, gone. This can prove to be among the hardest bugs to ﬁnd. If you have one of these, make certain there is no error and use -esym to suppress the message for a particular variable.
Supports AUTOSAR17 Rule M7-5-2
Supports AUTOSAR19 Rule M7-5-2
Supports CERT C DCL30-C - Declare objects with appropriate storage durations
Supports CWE-562 - Return of Stack Variable Address
Supports MISRA C 2004 Rule 17.6 - The address of an object with automatic storage shall not be assigned to another object that may persist after the ﬁrst object has ceased to exist.
Supports MISRA C 2012 Rule 18.6 - The address of an object with automatic storage shall not be copied to another object that persists after the ﬁrst object has ceased to exist
Supports MISRA C:2023 Rule 18.6 - The address of an object with automatic storage shall not be copied to another object that persists after the ﬁrst object has ceased to exist
Supports MISRA C:2025 Rule 18.6
Supports MISRA C++:2008 Rule 7-5-2 - The address of an object with automatic storage shall not be assigned to another object that may persist after the ﬁrst object has ceased to exist.
Supports MISRA C++:2023 Rule 6.8.3 - An assignment operator shall not assign the address of an object with automatic storage duration to an object with a greater lifetime

790
info
possibly truncated string promoted to type
This message is issued when it appears that there may have been an unintended loss of information during an operation involving integrals, the result of which is later converted to a ﬂoating point quantity. The operations that are scrutinized and reported upon by this message are: shift left and multiplication. Addition and subtraction are covered by note 942 . See also messages 647 and 776 .
Supports CERT C FLP06-C - Convert integers to ﬂoating point for ﬂoating-point operations
Supports CWE-681 - Incorrect Conversion between Numeric Types

791
info
a single line suppression followed a normal option
A temporary message suppression option (one having the form: !e...) followed a regular option. Was this intended?

792
info
casting void expression to void
A void expression has been cast to void. Was this intended?
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

793
info
ANSI/ISO minimum translation limit of integer 'string' exceeded, processing is unaﬀected
An ANSI/ISO minimum translation limit has been exceeded. These limits are described under the heading "Translation limits" in the ANSI/ISO C Standards and under the heading "Implementation Quantities" in the C++ standards. Programs exceeding these limits are not considered maximally portable. However, they may work for individual compilers.

The integer parameter indicates the numeric value that was exceeded and string provides a textual description of the limit in question.

Say a large program exceeds the ANSI/ISO limit of 4095 external identiﬁers. This will result in the message:

793 ANSI/ISO minimum translation limit of 4095 'external identifiers' 
   exceeded, processing is unaffected

It may not be obvious how to inhibit this message for identiﬁers while leaving other limits in a reportable state. The second parameter of the message is designated string and so the -estring may be used. Because the string contains a blank, quotes must be used. The option becomes:

-estring(793,"external identifiers')

See 17.10 Language Limits for additional information and a list of supported limits.
Supports CERT C DCL40-C - Do not create incompatible declarations of the same function or object
Supports MISRA C 2012 Rule 1.1 - The program shall contain no violations of the standard C syntax and constraints, and shall not exceed the implementation’s translation limits
Supports MISRA C:2023 Rule 1.1 - The program shall contain no violations of the standard C syntax and constraints, and shall not exceed the implementation’s translation limits
Supports MISRA C:2025 Rule 1.1

798
info
redundant char 'character'
The indicated character is redundant and can be eliminated from the input source. A typical example is a backslash on a line by itself.

799
info
numerical constant 'integer' larger than unsigned long
An integral constant was found to be larger than the largest value allowed for unsigned long quantities. By default, an unsigned long is 4 bytes but can be respeciﬁed via the option -sl#. If the long long type is permitted (see option +fll ) this message is automatically suppressed. See also message 417 .

801
info
goto statement used
A goto was detected. Use of the goto is not considered good programming practice by most authors and its use is normally discouraged. There are a few cases where the goto can be eﬀectively employed but often these can be rewritten just as eﬀectively without the goto. The use of goto statements can have a devastating eﬀect on the structure of large functions creating a mass of spaghetti-like confusion. For this reason its use has been banned in many venues.
Supports AUTOSAR17 Rule A6-6-1
Supports AUTOSAR19 Rule A6-6-1
Supports MISRA C 2004 Rule 14.4 - The goto statement shall not be used.
Supports MISRA C 2012 Rule 15.1 - The goto statement should not be used
Supports MISRA C:2023 Rule 15.1 - The goto statement should not be used
Supports MISRA C:2025 Rule 15.1
Supports MISRA C++:2023 Rule 9.6.1 - The goto statement should not be used

805
info
expected L"..." to initialize wide char string
An initializer for a wide character array did not use a preceding ’L’. For example:

wchar_t a[] = "abc";

was found whereas

wchar_t a[] = L"abc";

was expected.

806
info
small signed bitﬁeld
A small bit ﬁeld (less than an int wide) was found and the base type is signed rather than unsigned. Since the most signiﬁcant bit is a sign bit, this practice can produce surprising results. For example,

struct { int b:1; } s; 
s.b = 1; 
if( s.b > 0 ) /* should succeed but actually fails */ 
   ...

808
info
no explicit type given, int assumed
An explicit type was missing in a declaration. Unlike Warning 601 , the declaration may have been accompanied by a storage class or modiﬁer (qualiﬁer) or both. For example:

extern f(void);

will draw message 808. Had the extern not been present, a 745 would have been raised.

The keywords unsigned, signed, short and long are taken to be explicit type speciﬁers even though int is implicitly assumed as a base.
Supports CERT C DCL31-C - Declare identiﬁers before using them
Supports MISRA C 2004 Rule 8.2 - Whenever an object or function is declared or deﬁned, its type shall be explicitly stated.
Supports MISRA C 2012 Rule 8.1 - Types shall be explicitly speciﬁed
Supports MISRA C:2023 Rule 8.1 - Types shall be explicitly speciﬁed
Supports MISRA C:2025 Rule 8.1

809
info
likely returning address of local symbol through symbol
The value held by a pointer variable may have been the address of an auto variable. It is normally incorrect to return the address of an item on the stack because the portion of the stack allocated to the returning function is subject to being obliterated after return.

810
info
arithmetic modiﬁcation of custodial pointer
We deﬁne the custodial variable as that variable directly receiving the result of a malloc or new or equivalent call. It is inappropriate to modify such a variable because it must ultimately be free’ed or delete’ed. You should ﬁrst make a copy of the custodial pointer and then modify the copy. The copy is known as an alias. For example:

void f() { 
   int* custodian1 = (int*)malloc(sizeof(int)); 
   int* custodian2 = (int*)malloc(sizeof(int)); 
   int* alias = custodian2; 
 
   custodian1++;     // info 810 
 
   alias++;         // Okay 
}

22.3 Messages 1000-1999

1001
error
scope string must be a classstring
In an expression of the form X::Y, X must be a class name. [?, Section 10.4]

1002
error
invalid use of 'this' context
The keyword this refers to the class being passed implicitly to a member function. It is invalid outside a class member function. [?, Section 5.1]

1003
error
'this' cannot be used in a static member function declaration
A static member function receives no this pointer. [?, Section 9.5]

1004
error
right hand operand to 'string' has non-pointer-to-member type type
The .* and ->* operators require pointer to members on the right hand side. [?, Section 5.5]

1008
error
initializer on function does not look like a pure-speciﬁer
Some nonstandard extensions to C++ allow integers to follow ’=’ for declarations of member functions. If you are using such extensions, simply suppress this message. If only library headers are using this extension, use -elib(1008). [?, Section 10.3]

1012
error
return type not allowed for conversion function
The return type of a function introduced with ’operator type’ is type and may not be preceded with the same or any other type. [?, Section 12.3.2]

1013
error
symbol symbol is not a member of string
The second operand of a scope operator or a ’.’ or ’->’ operator is not a member of the class (struct or union) expressed or implied by the left hand operand. [?, Section 3.2]
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

1020
error
template specialization declared without a 'template<>' preﬁx
A class template specialization is generally preceded by a ’template’ clause as in:

template< class T > class A { };  // a template 
template<> class A<int> { };      // a specialization

If the ’template<>’ is omitted you will get this message but it will still be interpreted as a specialization. Before the standardization of template syntax was completed, a template specialization did not require this clause and its absence is still permitted by some compilers.

1022
error
function symbol must be a non-static member function
There are four operators not to be deﬁned except as class members. These are:

= () [] ->

The parameter symbol indicates which it is. [?, Section 13.4.3 and 13.4.6]

1023
error
call to symbol is ambiguous
A call to an overloaded function or operator is ambiguous. The candidates of choice are provided in the message. [?, Section 13.2]

1024
error
no matching function for call to symbol
A call to an overloaded function could not be resolved successfully because no function is declared with the same number of arguments as in the call. [?, Section 13.2]

1027
error
missing default argument for parameter symbol of function symbol
Default arguments need to be consecutive. For example

void f(int i=0, int j, int k=0);

is illegal. [?, Section 8.2.6]

1029
error
default argument repeated for parameter symbol in function symbol
A default value for a given argument for a given function should be given only once. [?, Section 8.2.6]

1031
error
local variable symbol used in default argument expression
Default values for arguments may not use local variables. [?, Section 8.2.6]

1032
error
non-static/explicit function symbol cannot be called without object
There was an attempt to call a non-static member function without specifying or implying an object that could serve as the basis for the this pointer. If the member name is known at compile time it will be printed with the message. [?, Section 5.24]

1033
error
static member functions cannot be virtual
You may not declare a static member function virtual. [?, Section 10.2]

1034
error
'static' can only be speciﬁed inside the class deﬁnition
This can come as a surprise to the novice C++ programmer. The word ’static’ within a class deﬁnition is used to describe a member that is alone and apart from any one object of a class. But such a member has program scope not ﬁle scope. The word ’static’ outside a class deﬁnition implies ﬁle scope not program scope. [?, Section 9.5]

1036
error
call to constructor of symbol is ambiguous
There is more than one constructor that can be used to make a desired conversion. [?, Section 12.3.2]

1037
error
conversion between types is ambiguous
There is more than one conversion function (of the form operator type () ) that will perform a desired conversion. [?, Section 12.3.2]

1038
error
type type not found, type assumed
We have found what appears to be a reference to a type but no such type is in scope. We have, however, been able to locate a type buried within another class. Is this what the user intended? If this is what is intended, use full scoping. If your compiler doesn’t support the scoping, suppress with -esym . [?, Section 3.2]

1040
error
non-friend class member symbol cannot have a qualiﬁed name
A declaration of the symbol X::Y appears within a class deﬁnition (other than for class X). It is not a friend declaration. Therefore it is in error.

1042
error
at least one class-like parameter is required for overloaded string
In deﬁning (or declaring) an operator you must have at least one class as an operand. [?, Section 13.4]

1043
error
cannot delete expression of type type
An expression being delete’d is a non-pointer, non-array. You may only delete what was created with an invocation of new. [?, Section 5.3.4]

1046
error
invalid use of member symbol in static/explicit object member function
The symbol is a non-static member of a class and hence requires a class instantiation. None is in sight. [?, Section class.static]

1051
error
redeﬁnition of symbol as diﬀerent kind of symbol
Whereas it is possible to overload a function name by giving it two diﬀerent parameter lists, it is not possible to overload a name in any other way. In particular, a function name may not also be used as a variable name. [?, Section 9.2]
Supports CERT C DCL36-C - Do not declare an identiﬁer with conﬂicting linkage classiﬁcations

1055
error
use of undeclared identiﬁer string; did you mean symbol?
Whereas in C you may call a function without a prior declaration, in C++ you must supply such a declaration. For C programs you would have received an Informational message (718 ) in this event. [?, Section 5.2.2]

1057
error
member symbol cannot be used without an object
The indicated member referenced via scope operator cannot be used in the absence of a this pointer. [?, Section 5.2.4]

1063
error
copy constructor for class symbol must pass its ﬁrst argument by reference
A constructor for a class closely resembles a copy constructor. A copy constructor for class X is typically declared as:

X(const X &)

If you leave oﬀ the ’&’ then a copy constructor would be needed just to copy the argument into the copy constructor. This is a runaway recursion. [?, Section 12.1]

1069
error
member initializer string does not name a non-static data member or base class of class symbol
Within a constructor initialization list, a name was found that did not correspond to either a direct base class of the class being deﬁned or a member of the class.

1071
error
constructor cannot have a return type
Constructors and destructors may not be declared with a return type, not even void. See ARM [?, Section 12.1 and 12.4]

1072
error
reference variable string must be initialized
A reference variable must have an initializer at the point of declaration.

1074
error
expected a namespace identiﬁer
In a declaration of the form:

namespace name = scoped-identifier

the scoped-identiﬁer must identify a namespace.

1075
error
ambiguous reference to symbol symbol
Two namespaces contain the same name. A reference to such a name could not be disambiguated. You must fully qualify this name in order to indicate the name intended.

1076
error
anonymous union assumed to be 'static'
Anonymous unions need to be declared static. This is because the names contained within are considered local to the module in which they are declared.

1079
error
could not ﬁnd '>' or ',' to terminate template parameter
The default value for a template parameter appears to be malformed. For example, suppose the user mistakenly substituted a ’]’ for a ’>’ producing the following:

template <class T = A< int ] > 
   class X 
   { 
   };

This will cause PC-lint Plus to process to the end of the ﬁle looking (in vain) for the terminating pointy bracket. Not ﬁnding it will cause this message to be printed. Fortunately, the message will bear the location of the malformed template.

1083
error
ambiguous conversion between 2nd and 3rd arguments of conditional operator; reason
If the 2nd operand can be converted to match the type of the 3rd, and the 3rd operand can be converted to match the type of the 2nd, then the conditional expression is considered ill-formed.

1088
error
a using declaration requires a qualiﬁed-id
This error is issued when a using-declaration references a name without the :: scope resolution operator; e.g.:

class A { 
protected: 
   int n; 
}; 
 
class B : public A { 
public: 
   using n; // Error 1088: should be 'using A::n;' 
};

See [?, Section 7.3.3 namespace.udecl].

1089
error
a using declaration must not name a namespace
This error is issued when the rightmost part of the qualiﬁed-id in a using-declaration is the name of a namespace. E.g.:

namespace N { 
   namespace Q { 
      void g(); 
   } 
} 
 
void f() { 
   using ::N::Q; // Error 1089 
   Q::g(); 
}

Instead, use a namespace-alias-deﬁnition:

namespace N { 
   namespace Q { 
      void g(); 
   } 
} 
 
void f() { 
   namespace Q = ::N::Q;   // OK 
   Q::g();               // OK, calls ::N::Q::g(). 
}

See [?], Issue 460.

1090
error
a using declaration must not name a template-id
This error is issued when the rightmost part of the qualiﬁed-id in a using-declaration is a template-id. E.g.:

template <class T> class A { 
protected: 
   template <class U> class B {}; 
}; 
 
struct D : public A<int> { 
public: 
   using A<int>::B<char *>; // Error 1090 
}; 
 
D::B<char *> bc;

Instead, refer to the template name without template arguments:

template <class T> class A { 
protected: 
   template <class U> class B {}; 
}; 
 
struct D : public A<int> { 
public: 
   using A<int>::B; // OK 
}; 
 
D::B<char *> bc;    // OK

See [?], 7.3.3 namespace.udecl.

1091
error
using declaration refers into symbol, which is not a base class of symbol
This error is issued when the nested-name-speciﬁer of the qualiﬁed-id in a using-declaration does not name a base class of the class containing the using-declaration; e.g.:

struct N { 
   void f(); 
}; 
 
class A { 
protected: 
   void f(); 
}; 
 
class B : A { 
public: 
   using N::f;    // Error 1091 
};

See [?], Issue 400.

1092
error
a using declaration that names a class member must be a member declaration
This error is issued when the nested-name-speciﬁer of the qualiﬁed-id in a using-declaration names a class but the using-declaration does not appear where class members are declared. E.g.:

struct A { 
   void f(); 
}; 
 
struct B : A { 
   void g() { using A::f; }   // Error 1092 
};

See [?], 7.3.3 namespace.udecl.

1093
error
symbol is not virtual and cannot be declared pure
A pure speciﬁer ("= 0") should not be placed on a function unless the function had been declared "virtual".

1096
error
an initializer for a delegating constructor must appear alone
C++11 requires that if a constructor delegates to another constructor, then the mem-initializer (the region between the colon and the function body) must contain only one item, and that item must be a call to another constructor (which is called the "target constructor"). Example

struct A { 
   int n; 
   A(int); 
   A(const A &p) : A(p.n) { }  // OK 
   A() : n(42), A(32) { }      // Error 1096 
};

1097
error
constructor symbol creates a delegation cycle
The speciﬁed constructor is a delegating constructor that contains a delegation cycle, either directly by delegating to itself or indirectly by calling another delegating constructor that eventually delegates back to the original constructor. If multiple constructors are in the cycle, the other constructors are provided via subsequent 891 supplemental messages. For example:

struct A { 
   int n; 
   A(int x) : A(x, 0) { }            // Error 1097 
   A(int x, int y) : A(x, y, 0) { } 
   A(int x, int y, int z) : A(x) { } 
};

1098
error
function template specialization symbol does not match any function template
This message is issued for a declaration where the user apparently intended to name a specialization of a function template (e.g., in an explicit specialization, an explicit instantiation or a friend declaration of specialization), but no previously-declared function template is matched. Example:

template<class T> void f( const T& ); // #1 
 
struct A{}; 
template<> void f( const A& );       // Ok 
// (A is the deduced argument to T.) 
 
struct B{}; 
template<> void f( const B );       // Error 1098. 
// (A template argument cannot be deduced for T.)

1099
error
function template specialization symbol ambiguously refers to more than one function template; explicitly specify template arguments to identify a particular function template
This message is issued for a declaration where the user apparently intended to name a specialization of a function template (e.g., in an explicit specialization, an explicit instantiation or a friend declaration of specialization), but the specialization matches multiple function templates, and none of the matched templates is more specialized than all of the other matching templates. The candidates (i.e., the matching templates) are provided in the message. Example:

template<class T> struct A {}; 
 
template<class T, class U> void f( T*, U  ); // #1 
template<class T, class U> void f( T, A<U> ); // #2 
 
struct B{}; 
template<> void f( B, A<B> );              // Ok 
// #1 does not match but #2 does. 
 
template<> void f( char*, A<int> );         // Error 1099 
// Both #1 and #2 match and neither is more specialized than the other.

This situation can be avoided in at least a couple of ways. One way is to explicitly specify one or more template arguments. Example

// continuing from above... 
template<> void f<char*>( char*, A<int> ); // Ok 
// #1 does not match but #2 does.

Another way is to use SFINAE (Substitution Failure Is Not An Error) tactics in the declaration of one or more function templates, e.g. with boost::enable_if.

1101
error
type of variable symbol cannot be deduced from its initializer
Example:

int f(void); 
int f(char*); 
auto n = f; // Error

In terms of deduction, this is equivalent to:

int f(void); 
int f(char *); 
template <class T> void g(const T &); 
 
void h(void) { 
   g(f);  // Error 
}

Here, ’f’ refers to multiple overloaded functions, so it is an ambiguous reference and T cannot be deduced. (Code like this could still be well-formed however, e.g. if g is overloaded with a non-template function whose parameter type is ’ptr-to-function returning int taking char*’.)

1102
error
string' type deduced inconsistently: type for symbol but type for symbol
When multiple variables are deﬁned in the same declaration, and when that declaration uses the keyword auto as the type-speciﬁer, the type for which auto is a placeholder must be the same for each variable. Example:

float g(void); 
char* s(); 
auto a = 42;         // Ok, auto is 'int' 
auto b = g();        // Ok, auto is 'float' 
auto c = 'q', 
    *d = s();       // Ok, auto is 'char' (for both c and d) 
auto x = 42, y = g();  // Error 1102 here

1103
error
non-integral/bit-precise type type is not a valid enum-base
When an enumeration type is declared with an explicit underlying type, that type must be integral. It must not be a bit-precise integral type. Example:

enum A : bool;             // ok 
enum B : short;            // ok 
enum C : unsigned long long;  // ok 
enum D : float;            // error 1103 
enum E : _BitInt(4);        // error 1103

1105
error
cannot overload a member function with a certain ref-qualiﬁer with a member function with diﬀerent ref-qualiﬁers
If an explicit ref qualiﬁer (’&’ or ’&&’) of a nonstatic member function is employed, an explicit ref qualiﬁer needs to be used with every member of the overload set. Thus:

class A { 
   void f(int)&; 
   void f(int); 
   void f(double); 
   void g(int); 
   void g(double); 
};

1107
error
invalid concatenation of wide string literals of diﬀerent kinds
Two string literals that diﬀerent types are being concatenated. Examples:

char *s = u"abc" U"def"; 
char *q = L"ghi" u"jkl";

This message is issued for mixing strings of char16_t, char32_t, and/or wchar_t (as shown). Literal string concatenation of any of these with an ordinary character literal is permitted and will receive Informational 707 .
Supports AUTOSAR17 Rule A2-14-2
Supports AUTOSAR19 Rule A2-13-2
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3
Supports MISRA C++:2023 Rule 5.13.7 - String literals with diﬀerent encoding preﬁxes shall not be concatenated

1108
error
call to deleted function string
This message is issued when an attempt is made to call a deleted function. For example:

void f( int ) = delete; 
void f( double ); 
void g( double d, int n ) { 
   f( d ); // Ok 
   f( n ); // Error 
}

1110
error
circular pointer delegation detected: explicit application of type::operator-> causes inﬁnite applications of the same operator
When an overloaded operator-> is used as in

a->b

it is eﬀectively expanded to:

a.operator->()->b

And this expansion repeats until an operator-> is found that does not yield a class type. But in the process of evaluating this expansion, it might be found that one of the operators returns a class type for which an overloaded operator-> was already expanded; in that case, Error 1110 is triggered. Example:

struct B; 
struct A { struct B& operator->(); }; 
struct B { struct A& operator->(); }; 
int f( A & p ) { p->g(); }          // Error

1112
error
function with trailing return type must specify return type 'auto', not string
or example, if you want to declare that f returns a pointer-to-int, you must write:

auto f() -> int *;

... and not:

auto *f() -> int;

This also applies to a type-id (e.g., in a cast to a pointer-to-function, or as an argument to a template type-parameter).

1116
error
virtual function symbol overrides function marked with 'string'
A derived class attempted to override a virtual function that is marked with the final virt-speciﬁer in a base class.

1117
error
non-virtual function symbol marked with 'string'
A virt-speciﬁer (final or override) was supplied to a non-virtual function.

1118
error
virtual function already marked 'string'
A virt-speciﬁer (final or override) was encountered multiple times for the speciﬁed virtual function.

1119
error
virtual function symbol marked 'override' does not override any member functions
A virtual function was marked with the override keyword but does not override a base class function.

1120
error
incomplete type type is not a valid range expression
An incomplete type was used as a range expression in a range-based for statement. A range expression must be a complete type.

1123
error
attempt to derive from class type marked as 'ﬁnal/sealed'
A class that was marked with the final class-virt-speciﬁer was used as a base class in a class declaration.

1124
error
digit separator not allowed: before/after digit sequence
A digit separator character was encountered within a numeric literal at a point where digit separators are not allowed. Digit separators are only allowed between digits of a numeric literal and cannot be adjacent to each other.

1125
error
a type cannot be deﬁned in a friend declaration
The deﬁnition of a type appeared in a friend declaration, this is not legal.

Example:

class A { 
   friend struct B;   // ok 
   friend struct C {}; // error 
};

1127
error
catch handler after catch(...)
A catch handler appeared following a catch(...) in the same try-catch statement, which invokes undeﬁned behavior.
Supports AUTOSAR17 Rule M15-3-7
Supports AUTOSAR19 Rule M15-3-7
Supports MISRA C++:2008 Rule 15-3-7 - Where multiple handlers are provided in a single try-catch statement or function-try-block, any ellipsis (catch-all) handler shall occur last.

1301
error
integer sequences must have non-negative sequence length
An attempt was made to instantiate the built-in template __make_integer_seq with a negative length.

1302
error
integer sequences must have integral element type
An attempt was made to instantiate the built-in template __make_integer_seq with a non-integral type. As the name implies, __make_integer_seq generates a sequence of integers.

1401
warning
non-static data member symbol not initialized by constructor symbol
The indicated non-static data member was not initialized by the speciﬁed constructor. Speciﬁcally, this means that the member does not have an in-class initializer and was neither directly initialized or assigned a value in the constructor nor did the constructor call any function that appeared to initialize this member.
Supports AUTOSAR17 Rule A12-1-1
Supports AUTOSAR19 Rule A12-1-1
Supports CWE-456 - Missing Initialization of a Variable

1404
warning
deleting an object of type type before that type is deﬁned
The following situation was detected:

class X; ... X *p; ... delete p;

That is, a placeholder declaration for a class is given and an object of that type is deleted before any deﬁnition is seen. This may or may not be followed by the actual class deﬁnition:

class X { ... };

A delete before the class is deﬁned as dangerous because, among other things, any operator delete that may be deﬁned within the class could be ignored.
Supports AUTOSAR19 Rule A5-3-3
Supports MISRA C++:2023 Rule 21.6.5 - A pointer to an incomplete class type shall not be deleted

1405
warning
header <typeinfo> must be included before 'typeid' is used
According to Section 5.2.8 (para 6) of the C++ standard [?], "If the header <typeinfo> (18.5.1) is not included prior to a use of typeid, the program is ill-formed." A typeid was found in the program but the required include was not.

1407
warning
incrementing expression of type bool
An increment operator was applied to an object of bool type; such use has been deprecated since C++98. The same eﬀect can be obtained by assigning the value true to the object. Note the decrementing an object of bool type has never been allowed in Standard C++ and will instead be greeted with an error.
Supports AUTOSAR17 Rule A1-1-1
Supports AUTOSAR19 Rule A1-1-1

1411
warning
member symbol with diﬀerent signature hides virtual member symbol
A member function has the same name as a virtual member of a derived class but it has a diﬀerent signature (diﬀerent parameter list). This is legal but suspicious because it looks as though the function would override the virtual function but doesn’t. You should either adjust the parameters of the member so that the signatures conform or choose a diﬀerent name. See also message 1511 .

1413
warning
function symbol is returning a temporary via a reference
It appears that a function (identiﬁed as symbol in the message) declared to return a reference is returning a temporary. The C++ standard (Section 12.2), in addressing the issue of binding temporary values to references, says "A temporary bound to the returned value in a function return statement ... persists until the function exits". Thus the information being returned is not guaranteed to last longer than the function being called.

It would probably be better to return by value rather than reference. Alternatively, you may return a static variable by reference. This will have validity at least until the next call upon the same function.

1414
warning
assigning address of local variable symbol to member of 'this' object
The address of an auto variable was taken and assigned to a this member in a member function. For example:

struct A { 
   char *x; 
   void f() { 
      char y[10]; 
      x = y;      // warning 1414 
   } 
};

Here, the address of y is being passed to member x but this is dangerous (if not ridiculous) since when the function returns the storage allocated for y is deallocated and the pointer could very easily harm something.

1415
warning
pointer to non-POD type passed to function symbol (context)
A non-POD class is one that goes beyond containing just Plain Old Data (POD). In particular, it may have private or protected data or it may have constructors or a destructor or a copy assignment. All of these things disqualify it from being a POD. A POD is fully deﬁned in the C++ standard (Clause 9).

Some functions (such as memcpy, memcmp, memmove, etc.) are expected to be given only pointers to POD objects. The reason is that only POD objects have the property that they can be copied to an array of bytes and back again with a guarantee that they will retain their original value. (See Section 3.9 of the C++ standard [?]). See also Semantic pod(i).
Supports AUTOSAR19 Rule A12-0-2
Supports CWE-687 - Function Call With Incorrectly Speciﬁed Argument Value

1416
warning
reference symbol is not yet bound to a value when used here
This message is usually issued when a reference to a member of a class is used to initialize a reference to another member of the same class before the ﬁrst member was initialized. For example:

class C { 
   int &n, &m; 
   C(int &k) : n(m), m(k) { /* ... */ } 
};

Here m is initialized properly to be identical to k. However, the initialization of n, taking place, as it does, before m is so initialized, is erroneous. It is undeﬁned what location n will reference.
Supports CWE-457 - Use of Uninitialized Variable

1417
warning
string must explicitly initialize the reference/const member symbol
This message is issued when a reference data member of a class does not appear in a mem-initializer. For example, the following code will result in a Warning 1417 for symbol m since a mem-initializer is the only way that m can be reference initialized.

class C { 
   int &n, &m; 
   C(int &k) : n(k) { /* ... */ } 
};

1419
warning
throwing the NULL macro will invoke an implementation-deﬁned handler; NULL may be deﬁned as either an integer literal equal to zero or the keyword nullptr
The macro NULL was passed to a throw expression. Since C++11, the NULL macro can be deﬁned as expanding to either an integer literal with a zero value or nullptr, the choice of which is implementation deﬁned. The handler that catches the exception may depend on how the NULL macro is deﬁned. Prior to C++11, NULL could only be deﬁned as an integer type and will not be caught by an exception handler expecting a pointer type, which may not be obvious.
Supports AUTOSAR17 Rule M15-1-2
Supports AUTOSAR19 Rule M15-1-2
Supports MISRA C++:2008 Rule 15-1-2 - NULL shall not be thrown explicitly.

1420
warning
'mutable' applied to a reference type is non-standard
C++ expressly forbids the use of the mutable keyword on a reference type. Despite this, at least one vendor’s compiler not only supports this use but relies on the ability to do so in their own library headers. If your compiler supports this use, you can suppress this message.

1421
warning
template parameter illegally redeﬁnes default argument
C++ explicitly forbids redeﬁning the default argument of a template parameter. If your compiler allows this, you can suppress this message.

1422
warning
default constructor symbol defaulted outside of class
This message is issued when the default constructor for a class is declared within its class deﬁnition and then defaulted outside of the class deﬁnition. C++ performs initialization of classes with user supplied default constructors (declared but not defaulted in the class deﬁnition) diﬀerently than classes without a user provided default constructor.

1423
warning
reinterpret_cast from type to type has undeﬁned behavior
The C++ Standard speciﬁes the conversions that can be performed using reinterpret_cast. A conversion was attempted using reintepret_cast that was not included in this list which will result in undeﬁned behavior.

1424
warning
symbol has been previously moved but is used
A moved-from object was used that has not been reinitialized. Moving an object indicates that its resources are intended to be transfered and can be left in an unspeciﬁed state. Using a moved-from object can result in behavior that is unusual or lacks portability.

std::string s1{"Hello World"}; 
std::string s2{std::move(s1)}; 
std::cout << s1 << std::endl;  // warning 1424

Message 1765 will exclusively report uses of a self-moved object. Custom move functions can be added with the option -sem using the move semantic.
Supports AUTOSAR17 Rule A12-8-3
Supports AUTOSAR19 Rule A12-8-3
Supports MISRA C++:2023 Rule 28.6.3 - An object shall not be used while in a potentially moved-from state

1501
warning
data member symbol has zero size
A data member had zero size. It could be an array of zero length or a class with no data members. Check your code to make sure this is not an error. Some libraries employ clever templating, which will elicit this message. In such a case it is necessary for you to inhibit the message outright (using -e1501) or through a judicious use of -esym(1501,...).

struct A { 
 int b[0];  // warning 1501 
};

1502
warning
deﬁned object symbol of type symbol has no non-static data members
A variable is being instantiated that belongs to a class that contains no data members (either directly or indirectly through inheritance). Note that this message can be suppressed using -esym with either the object name (given in the ﬁrst symbol paramter) or the class name (given in the second symbol parameter). [?, Section 9]

1504
warning
anonymous structure declaration without the '+fas' option
An untagged struct declaration appeared within a struct/union and has no declarator. It is not treated like an anonymous union. Was this intended?

1505
warning
base speciﬁer with no access speciﬁer is implicitly public/private
A base class speciﬁer provides no access speciﬁer (public, private or protected). An explicit access speciﬁer is always recommended since the default behavior is often not what is expected. For example:

class A : B { int a; };

would make B a private base class by default.

class A : private B { int a; };

is preferred if that’s what you want. [?, Section 11.1]

1506
warning
call to virtual function symbol within a string
A call to a virtual function was found in a constructor or a destructor of a class; such a call will not consider overrides from derived classes (as they have not been constructed yet, or have already been destroyed). This message will not be issued in any of the following cases:

The call was qualiﬁed explicitly using the scope operator, inhibiting the virtual call mechanism.
The virtual function was declared with the ﬁnal speciﬁer.
The class of the constructor or destructor was declared with the ﬁnal speciﬁer.

[?, Section 9]
Supports AUTOSAR17 Rule M12-1-1
Supports AUTOSAR19 Rule M12-1-1
Supports MISRA C++:2008 Rule 12-1-1 - An object’s dynamic type shall not be used from the body of its constructor or destructor.
Supports MISRA C++:2023 Rule 15.1.1 - An object’s dynamic type shall not be used from within its constructor or destructor

1507
warning
use of 'delete' on pointer-to-array type type should be 'delete[]'
The type of an object to be delete’d is usually a pointer. This is because operator new always returns a pointer and delete may only delete that allocated via new. Perhaps this is a programmer error attempting to delete a local or global array? [?]

1509
warning
the destructor of derived class type is non-trivial, but the destructor of base class type is not virtual
The indicated class is a base class for some derived class. It has a non-virtual destructor. Was this a mistake? It is conventional to virtualize destructors of base classes so that it is safe to delete a base class pointer. [?]

1510
warning
the destructor of derived class type is non-trivial, but no destructor provided for base class type
The indicated class is a base class for some derived class that has a destructor. The base class does not have a destructor. Is this a mistake? The diﬃculty that you may encounter is this; if you represent (and manipulate) a heterogeneous collection of possibly derived objects via a pointer to the base class then you will need a virtual base class destructor to invoke the derived class destructor. [?, Section 4]

1511
warning
member function symbol hides non-virtual 'string' member symbol
The named member of a derived class hides a similarly named member of a base class. Moreover, the base class member is not virtual. Is this a mistake? Was the base member supposed to have been declared virtual? By unnecessarily using the same name, confusion could be created. The string parameter contains the member access of the hidden function (one of public, protected, or private) which can be used with -estring to suppress the message for e.g. hidden private functions using -estring(1511,private). This message is not issued for assignment operators or deleted member functions.
Supports AUTOSAR17 Rule A10-2-1
Supports AUTOSAR19 Rule A7-3-1
Supports AUTOSAR19 Rule A10-2-1

1513
warning
storage class ignored for member declaration
A class member was declared with the extern or register storage class speciﬁer. Member declarations are not allowed to be declared as extern or register.

1516
warning
data member symbol hides inherited member symbol
A data member of a class happens to have the same name as a member of a base class. Was this deliberate? Identical names can cause confusion. To inhibit this message for a particular symbol or for an identiﬁable set of symbols use -esym() .

1520
warning
multiple copy/move assignment operators for class symbol
More than one copy assignment operator or more than one move assignment operator has been declared for a given class. For example, for class X there may have been declared:

void operator=(X); 
void operator=(X) const;

Which is to be used for assignment?

1521
warning
multiple copy/move constructors for class symbol
For a given class, more than one function was declared that could serve as a copy or move constructor. Typically, this means that you declared both X( X& ) and X( const X& ) for the same class. This is probably a mistake.

1524
warning
new in constructor for class symbol which has no explicit destructor
A call to new has been found in a constructor for a class for which no explicit destructor has been declared. A destructor was expected because how else can the storage be freed? [?, Section class.free]

1526
warning
undeﬁned member function symbol
A non-private member function (named in the message) of a non-library class was not deﬁned. This message is suppressed for unit checkout (-unit_check option).

1527
warning
undeﬁned static data member symbol
A static data member (named in the message) of a non-library class was not deﬁned. In addition to its declaration within the class, it must be deﬁned in some module. This message is suppressed for unit checkout (-unit_check option).

1529
warning
assignment operator symbol should check for self-assignment
The assignment operator does not appear to be checking for assignment of the value of a variable to itself (assignment to this). Speciﬁcally, PC-lint Plus is looking for the ﬁrst statement of the assignment operator be an if statement which compares this to either &argument or std::addressof(argument) using either == or !=.

It is important to check for a self assignment so as to know whether the old value should be subject to a delete operation. This is often overlooked by a class designer since it is counter-intuitive to assign to oneself. But, through the magic of aliasing (pointers, references, function arguments) it is possible for an unsuspecting programmer to stumble into a disguised self-assignment. [?, Item 17]

If you are currently using the following test

if( arg == *this)

we recommend you replace this with the more eﬃcient:

if( &arg == this || arg == *this)

Supports AUTOSAR17 Rule A12-8-5
Supports AUTOSAR19 Rule A12-8-5
Supports MISRA C++:2023 Dir 15.8.1 - User-provided copy assignment operators and move assignment operators shall handle self-assignment

1531
warning
member allocation function symbol of non-ﬁnal class symbol does not reference the allocation size
A member allocation function (operator new or delete, including array forms) was declared within a non-ﬁnal class and does not appear to utilize the dynamic size of the allocation. The size parameter may have been omitted entirely (in the case of operator delete) or was never referenced within the function. Because the enclosing class is not ﬁnal, another class could derive from this class and inherit a member allocation function that relies on a ﬁxed size appropriate only for the base class.

1532
warning
operator-delete should check ﬁrst parameter for null
A member operator delete should check its argument for NULL as it is unspeciﬁed whether deallocation functions are invoked when a null pointer is deleted.

1533
warning
repeated friend declaration for symbol symbol
A friend declaration for a particular symbol (class or function) was repeated in the same class. Usually this is a harmless redundancy.

1534
warning
static variable symbol deﬁned within inline function symbol in header 'ﬁle'
A static variable (symbol) was found within an inline function within a header ﬁle. This can be a source of error since the static variable will not retain the same value across multiple modules. Rather each module will retain its own version of the variable. If multiple modules need to use the function then have the function refer to an external variable rather than a static variable. Conversely, if only one module needs to use the function then place the deﬁnition of the function within the module that requires it. [?, Item 26]

1535
warning
member function symbol exposes lower access pointer member symbol
A member function is returning an address being held by the indicated member symbol (presumably a pointer). The member’s access (such as private or protected) is lower than the access of the function returning the address.
Supports CWE-495 - Private Data Structure Returned From A Public Method
Supports CWE-767 - Access to Critical Private Variable via Public Method

1536
warning
member function symbol exposes lower access member symbol
A member function is returning the non-const address of a member either directly or via a reference. Moreover, the member’s access (such as private or protected) is lower than the access of the function returning the address. For example:

class X { 
private: 
   int a; 
public: 
   int *f() { return &a; } 
};

This looks like a breach of the access system [?, Item 30]. You may lower the access rights of the function, raise the accessibility of the member, or make the return value a const pointer or reference. In the above example you could change the function to:

const int *f() { return &a; }

Supports CWE-495 - Private Data Structure Returned From A Public Method
Supports CWE-767 - Access to Critical Private Variable via Public Method
Supports MISRA C++:2008 Rule 9-3-2 - Member functions shall not return non-const handles to class-data.

1537
warning
const member function symbol exposes pointer/smart pointer member symbol as pointer/smart pointer to non-const
A const function is behaving suspiciously. It is returning a non-static pointer data member, or a pointer to data that is pointed to by a non-static data member, without a const qualiﬁer on the pointee type. For example,

class X { 
   int *p; 
   int *f() const { return p; }  // warning 1537 
};

Since f is supposedly const and since p is presumptively pointing to data that is logically part of class X, we certainly have the potential for a security breach. Either return a pointer to const or remove the const modiﬁer to the function. [?, Item 29] This message will not be issued when returning a function pointer.

In C++ code, smart pointers are also checked. Any class with a constructor that contains a shared_ptr_constructor, unique_ptr_constructor, or weak_ptr_constructor semantic is considered a smart pointer.

See message 3537 for returning a non-const reference to a data member in a const member function.
Supports AUTOSAR17 Rule M9-3-1
Supports AUTOSAR19 Rule M9-3-1
Supports CWE-495 - Private Data Structure Returned From A Public Method
Supports MISRA C++:2008 Rule 9-3-1 - const member functions shall not return non-const pointers or references to class-data.

1538
warning
base class name absent from initializer list for copy/move constructor
The indicated base class did not appear in the initializer list for a copy or move constructor. Was this an oversight? If the initializer list does not contain an initializer for a base class, the default constructor is used for the base class. This is not normally appropriate for a copy or move constructor. The following is more typical:

class B { ... }; 
class D : public B { 
   D( const D &arg ) : B( arg ) { ... } 
   ... 
};

1539
warning
member symbol not assigned by assignment operator symbol
The indicated symbol was not assigned by an assignment operator. Was this an oversight? It is not strictly necessary to initialize all members in an assignment operator because the ’this’ class is presumably already initialized. But it is easy to overlook the assignment of individual members. It is also easy to overlook your responsibility to assign base class members. This is not done for you automatically. [?, Item 16]

The message is not given for const members or reference members. If you have a member that is deliberately not initialized you may suppress the message for that member only using -esym .
Supports CWE-456 - Missing Initialization of a Variable

1540
warning
non-static pointer data member symbol not deallocated nor zeroed by destructor symbol
The indicated member is a non-static pointer member of a class that was apparently not freed by the class destructor. Was this an oversight? By freeing, we mean either a call to the free() function or use of the delete operator. If the pointer is intended only to point to static information during its lifetime then, of course, it never should be freed. In that case you should signal closure by assigning it the NULL pointer (0).

1541
warning
non-static data member symbol possibly not initialized by constructor symbol
The indicated non-static data member may not have been initialized by the speciﬁed constructor. Speciﬁcally, this means that the member does not have an in-class initializer, was not present in the member-initializer list, and was assigned a value (directly or indirectly by a called function) in only some of the paths that the constructor takes.

1544
warning
value of variable symbol is indeterminate due to run time initialization of symbol
A variable (identiﬁed by symbol) was used in the run-time initialization of a static variable. However this variable itself was initialized at run-time. Since the order of initialization cannot be predicted this is the source of a possible error.

Whereas addresses are completely known at initialization time, values may not be. Whether the value or merely the address of a variable is used in the initialization of a second variable is not an easy thing to determine when an argument is passed by reference or via pointer. For example, given struct X deﬁned as:

struct X { 
   X(const X &); 
   X(); 
};

a module containing the deﬁnition:

extern X x1; 
X x2 = x1;

and another module that deﬁnes x1, PC-lint Plus will issue a message similar to:

warning 1544: value of variable 'x2' is indeterminate due to run 
   time initialization of 'x1' 
X x2 = x1; 
 ^

It is theoretically possible, but unlikely, that the constructor X() is interested only in the address of its argument and not its current value. If so, it only means you will be getting a spurious report, which you can suppress based on variable name. However, if the const is missing when passing a reference parameter (or a pointer parameter) then we cannot easily assume that values are being used. In this case no report will be issued. The moral is that if you want to get the checking implied by this message you should make your constructor reference arguments const. This message is suppressed for unit checkout (-unit_check option).

Message 3708 is available to diagnose all instances of a static or thread storage duration variable being initialized without a constant-initializer.

1546
warning
throw outside try in destructor body
The body of a destructor (signature provided within the message) contains a throw not within a try block. This is dangerous because destructors are themselves triggered by exceptions in sometimes unpredictable ways. The result can be a perpetual loop. [?, Item 11]
Supports MISRA C++:2008 Rule 15-3-1 - Exceptions shall be raised only after start-up and before termination of the program.
Supports MISRA C++:2008 Rule 15-5-1 - A class destructor shall not exit with an exception.
Supports MISRA C++:2008 Rule 15-5-3 - The terminate() function shall not be called implicitly.

1547
warning
assignment of array of derived class to pointer to base class (context)
An assignment from an array of a derived class to a pointer to a base class was detected. For example:

class B { }; 
class D : public B {}; 
D a[10]; 
B *p = a;       // Warning 1547 
B *q = &a [0];   //OK

In this example p is being assigned the address of the ﬁrst element of an array. This is fraught with danger since access to any element other than the zeroeth must be considered an error (we presume that B and D actually have or have the potential to have diﬀerent sizes). [?, Item 3]

We do not warn about the assignment to q because it appears that the programmer realizes the situation and wishes to conﬁne q to the base object of the zeroeth element of a only. As a further precaution against inappropriate array access, out of bounds warnings are issued for subsequent references to p[1] and q[1].

1548
warning
exception speciﬁcation in declaration does not match previous declaration
Two declarations were found for the same function with inconsistent exception speciﬁcations.

void fn() noexcept;  // warn 1548 
void fn();  // warn 1548

The exception speciﬁcations of functions will not be checked across diﬀerent modules. See message 3548 which reports discrepancies in throwing potential across function declarations in diﬀerent modules.
Supports AUTOSAR17 Rule A15-4-3
Supports AUTOSAR19 Rule A15-4-3
Supports MISRA C++:2008 Rule 15-4-1 - If a function is declared with an exception-speciﬁcation, then all declarations of the same function (in other translation units) shall be declared with the same set of type-ids.

1549
warning
exception of type type thrown from function symbol is not in throw list
An exception was thrown (i.e., a throw was detected) within a function and not within a try block; more over the function contains a throw speciﬁcation but the exception thrown was not on the list. If you provide an exception speciﬁcation, include all the exception types you potentially will throw. [?, Item 14]
Supports MISRA C++:2008 Rule 15-5-2 - Where a function’s declaration includes an exception-speciﬁcation, the function shall only be capable of throwing exceptions of the indicated type(s).

1550
warning
exception 'name' thrown by function symbol is not on throw-list of function symbol
A function was called (ﬁrst symbol) that was declared as throwing an exception. The call was not made from within a try block and the function making the call (second symbol) had an exception speciﬁcation that did not include one of the types speciﬁed in the called function’s exception speciﬁcation. Either add the exception to the calling function’s exception list, or place the call inside a try block and catch the throw. [?, Item 14]

1551
warning
function symbol called outside of a try block in destructor symbol is not declared as never throwing
A call to a function (given by the ﬁrst symbol) was made from within a destructor given by the second symbol. The called function was declared as potentially throwing an exception. Such exceptions need to be caught within a try block because destructors should never throw exceptions. [?, Item 11].

1552
warning
converting pointer to array of derived to pointer to base
This warning is similar to Warning 1547 and is sometimes given in conjunction with it. It uses value tracking to determine that an array (that could be dynamically allocated) is being assigned to a base class pointer. For example,

Derived *d = new Derived[10]; 
Base *b; 
b = d;      // Warning 1552 
b = &d[0];  //OK

This case is an issue because if one tries to access b[i], where i is an index value, the compiler will attempt to access the object with the address i * sizeof(Base) from b. However, since the size of Derived is almost certain to be larger than the size of Base, this object is not the i-th Derived object.

[?, Item 3] Also, see the article by Mark Nelson (Bug++ of the Month, Windows Developer’s Journal, May 1997, pp. 43-44).

1554
warning
shallow pointer copy of symbol in copy constructor symbol
In a copy constructor a pointer was merely copied rather than recreated with new storage. This can create a situation where two objects have the same data and this, in turn, causes problems when these objects are deleted or modiﬁed. For example, the following class will draw this warning:

class X { 
   char *p; 
   X(const X &x) { p = x.p; } 
};

Here, member p is expected to be recreated using new or some variant.

1555
warning
shallow pointer copy of symbol in copy assignment operator symbol
In a copy assignment operator a pointer was merely copied rather than recreated with new storage. This can create a situation where two objects have the same data and this, in turn, causes problems when these objects are deleted or modiﬁed. For example, the following class will draw this warning:

class X { 
   char *p; 
   X &operator=(const X &x) { p = x.p; } 
};

Here, member p is expected to be recreated using new or some variant.

1556
warning
initialization could be confused with array allocation
A new expression had the form new T(integer) where type T has no constructor. For example:

new int(10);

will draw this warning. The expression allocates an area of storage large enough to hold one integer. It then initializes that integer to the value 10. Could this have been a botched attempt to allocate an array of 10 integers? Even if it was a deliberate attempt to allocate and initialize a single integer, a casual inspection of the code could easily lead a reader astray.

The warning is only given when the type T has no constructor. If T has a constructor then either a syntactic error will result because no constructor matches the argument or a match will be found. In the latter case no warning will or should be issued.

1558
warning
inline virtual function is unusual
The function declared both virtual and inline has been detected. An example of such a situation is as follows:

class C { 
   virtual inline void f(); 
};

Virtual functions by their nature require an address and so inlining such a function seems contradictory. We recommend that the inline function speciﬁer be removed.

1559
warning
uncaught exception 'name' may be thrown in destructor symbol
The named exception occurred within a try block and was either not caught by any handler or was caught but then thrown from the handler. Destructors should normally not throw exceptions. [?, Item 11]
Supports CWE-248 - Uncaught Exception

1560
warning
uncaught exception 'name' not on throw-list of function symbol
A direct or indirect throw of the named exception occurred within a try block and was either not caught by any handler or was rethrown by the handler. Moreover, the function has an exception speciﬁcation and the uncaught exception is not on the list. Note that a function that fails to declare a list of thrown exceptions is assumed to potentially throw any exception.
Supports CWE-248 - Uncaught Exception
Supports MISRA C++:2008 Rule 15-3-4 - Each exception explicitly thrown in the code shall have a handler of a compatible type in all call paths that could lead to that point.

1562
warning
exception speciﬁcation for symbol is not a subset of symbol
The ﬁrst symbol is that of an overriding virtual function for the second symbol. The exception speciﬁcation for the ﬁrst was found not to be a subset of the second. For example, it may be reasonable to have:

struct B  { virtual void f() throw(B); }; 
struct D:B { virtual void f() throw(D); };

Here, although the exception speciﬁcations are not identical, the exception D is considered a subset of the base class B.

It would not be reasonable for D::f() to throw an exception outside the range of those thrown by B::f() because in general the compiler will only see calls to B::f() and it should be possible for the compiler to deduce what exceptions could be thrown by examining the static call.
Supports AUTOSAR17 Rule A15-4-3
Supports AUTOSAR19 Rule A15-4-3

1563
warning
unparenthesized assignment as false expression of conditional operator
The third argument to ?: contained an unparenthesized assignment operator such as

p ? a : b = 1

If this is what was intended you should parenthesize the third argument as in:

p ? a : (b = 1)

Not only is the original form diﬃcult to read but C, as opposed to C++, would parse this as:

(p ? a : b) = 1

1564
warning
converting integer constant expression, which evaluates to integer but is not an integer literal equal to zero or one, to bool
An integer constant expression other than the integer literal 0 or 1 was implicitly converted to bool. It may have been unintended that the value will essentially be discarded as the result of the expression will depend only on whether or not it was zero. If the Boolean use of this expression was intentional it could be explicitly compared != 0 to clarify the intent (note that Boolean comparison against integral values other than 0 is discouraged because all non-zero values are equally true — see message 697 ).
Supports MISRA C++:2023 Rule 7.0.2 - There shall be no conversion to type bool

1565
warning
non-static data member symbol not initialized by initializer function symbol
A function dubbed ’initializer’ by a -sem option is not initializing (i.e., assigning to) every data member of a class. const members theoretically can be initialized only via the constructor so that these members are not candidates for this message.

1566
warning
non-static data member symbol may have been initialized in a separate method but no '-sem(name,initializer)' option was seen
A class data member (whose name and location are indicated in the message) was not directly initialized by a constructor. It may have been initialized by a separately called member function. If this is the case you may follow the advice given in the message and use a semantic option to inform PC-lint Plus that the separately called function is in fact an ’initializer’. For example:

class A { 
   int a; 
public: 
   void f(); 
   A() { f(); } 
};

Here f() is presumably serving as an initializer for the constructor A::A(). To inform PC-lint Plus of this situation, use the option:

-sem( A::f, initializer )

This will suppress Warning 1566 for any constructor of class A that calls A::f.

1570
warning
binding reference ﬁeld symbol to non-reference parameter symbol
In a constructor initializer, a reference class member is being initialized to bind to an auto variable. Consider:

class X { int &n; X(int k) :n(k) {} };

In this example member n is being bound to variable k, which although a parameter, is nonetheless placed into auto storage. But the lifetime of k is only the duration of the call to the constructor, whereas the lifetime of n is the lifetime of the class object constructed.

1571
warning
returning an auto variable symbol via a reference type
A function that is declared to return a reference is returning an auto variable (that is not itself a reference). The auto variable is not guaranteed to exist beyond the lifetime of the function. This can result in unreliable and unpredictable behavior.

1572
warning
initializing a static reference variable with an auto variable symbol
A static variable has a lifetime that will exceed that of the auto variable that it has been bound to. Consider

void f( int n ) { static int& r = n; ... }

The reference r will be permanently bound to an auto variable n. The lifetime of n will not extend beyond the life of the function. On the second and subsequent calls to function f the static variable r will be bound to a non-existent entity.

1575
warning
use of the delete operator with argument of void pointer type results in undeﬁned behavior
The delete operator was supplied an argument having pointer-to-void type. For example:

   void* ptr = new int(20); 
   delete ptr;  // Warning 1575

According to the C++ standard, the resulting behavior is undeﬁned.

1576
warning
explicit specialization is not in the same ﬁle as specialized function template symbol
An explicit specialization of a function template was found to be declared in a ﬁle other than the one in which the corresponding function template is declared. Two identical calls in two diﬀerent modules on the same function template could then have two diﬀering interpretations based on the inclusion of header ﬁles. The result is undeﬁned behavior.

As if this wasn’t enough, if the explicit specialization could match two separate function templates then the result you obtain could depend upon which function templates are in scope.

See also the next message.
Supports AUTOSAR17 Rule M14-7-3
Supports AUTOSAR19 Rule A14-7-2
Supports MISRA C++:2008 Rule 14-7-3 - All partial and explicit specializations for a template shall be declared in the same ﬁle as the declaration of their primary template.

1578
warning
non-static pointer data member symbol not deallocated nor zeroed by cleanup function symbol
The indicated member is a non-static data member of a class that was apparently not cleared by a function that had previously been given the cleanup semantic. By clearing we mean that the pointer was either zeroed or the storage associated with the pointer released via the free function or its semantic equivalent or some form of delete. See also Warning 1540 .

1579
warning
non-static pointer data member symbol may have been zeroed or freed in a separate method but no '-sem(name,cleanup)' option was seen
A class data member (whose name and location are indicated in the message) was not directly freed by the class destructor. There was a chance that it was cleared by a separately called member function. If this is the case you may follow the advice given in the message and use a semantic option to inform PC-lint Plus that the separately called function is in fact a ’cleanup’ function. For example:

class A { 
   int *p; 
public: 
   void release_ptrs(); 
   ~A() { release_ptrs(); } 
};

Here release_ptrs() is presumably serving as a cleanup function for the destructor ~A::A(). To inform PC-lint Plus of this situation, use the option:

-sem( A::release_ptrs, cleanup )

A separate message (Warning 1578 ) will be issued if the cleanup function fails to clear all pointers. See also Warning 1566 .

1705
info
static member symbol could be accessed using a nested name speciﬁer instead of applying operator 'string' to an instance of class symbol
A static class member was accessed using a class object and -> or . notation. For example:

s.member

p->member

But an instance of the object is not necessary. It could just as easily have been referenced as:

X::member

where X is the class name. [?, Section class.static]

1706
info
extra qualiﬁcation on member symbol within a class
Class members within a class are not normally declared with the scope operator. For example:

class X { int X::n; };

will elicit this message. If the (redundant) class speciﬁcation (X::) were replaced by some diﬀerent class speciﬁcation and the declaration was not friend an error (1040 ) would be issued. [?, Section 9.2]

1707
info
static assumed for symbol
operator new() and operator delete(), when declared as member functions, should be declared as static. They do not operate on an object instantiation (implied this pointer). [?, Section 12.5]

1710
info
missing 'typename' prior to dependent type name 'string'
This message is issued when the standard requires the use of ’typename’ to disambiguate the syntax within a template where it may not be clear that a name is the name of a type or some non-type. (See C++ Standard [?], Section temp.res, Para 2). Consider:

template <class T> 
class A { 
   T::N x;  // Info 1710 
};

while technically ill-formed, some compilers will accept this construct since the only interpretation consistent with valid syntax is that T::N represents a type. (But if the ’x’ weren’t there it would be taken as an access declaration and more frequently would be a non-type.)

1711
info
class symbol has a virtual function but is not inherited
The given class has a virtual function but is not the base class of any derivation. Was this a mistake? There is no advantage to making member functions virtual unless their class is the base of a derivation tree. In fact, there is a disadvantage because there is a time and space penalty for virtual functions. This message is not given for library classes and is suppressed for unit checkout. [?, section 4]

1714
info
member function symbol not referenced
A non-private member function was not referenced. This message is automatically suppressed for unit checkout (-unit_check ) and for members of a library class.
Supports AUTOSAR17 Rule M0-1-10
Supports AUTOSAR19 Rule M0-1-10
Supports MISRA C++:2008 Rule 0-1-10 - Every deﬁned function shall be called at least once.

1715
info
static member symbol not referenced
A static data member of a class was not referenced. This message is automatically suppressed for unit checkout (-unit_check ) and for members of a library class.
Supports AUTOSAR17 Rule M0-1-3
Supports AUTOSAR19 Rule M0-1-3
Supports MISRA C++:2008 Rule 0-1-3 - A project shall not contain unused variables.

1719
info
reference parameter of copy assignment operator symbol should be type
The typical assignment operator for a class is of the form:

X& operator =(const X &)

If the argument is not a reference then your program is subject to implicit function calls and less eﬃcient operation. [?, Section 13.4.3]

1720
info
reference parameter of copy assignment operator symbol should be type
The typical assignment operator for a class is of the form:

X& operator =(const X &)

If the argument is not const then your program will not be diagnosed as completely as it might otherwise be. [?, Section 13.4.3]

1721
info
operator=() for class symbol is not a copy nor move assignment operator
Class assignment operators typically have one of the following forms:

X& operator=(const X &);  // copy assignment 
X& operator=(X &&);      // move assignment

A member function whose name is operator= but does not have one of these forms is unusual and may be a subtle source of bugs. If this is not an error you may selectively suppress this message for the given class.

1722
info
assignment operator symbol should return type
The typical assignment operator for a class X is of the form:

X& operator =(const X &);

The reason for returning a reference to class is to support multiple assignment as in:

a = b = c

22.4 Messages 2000-2999

2001
error
request for string integer type with at least integer bits could not be processed
An appropriately sized integer type could not be found when attempting to determine the smallest integer type with enough bits to represent a bitﬁeld or an integer constant expression.

2005
error
hex/octal escape sequence out of range
The size of a character constant speciﬁed with \xddd or \xhhh equaled or exceeded 2**b where b is the number of bits in a byte (established by the -sb option). The default is -sb8.

Note that in PC-lint Plus 2.1 and earlier this message was previously emitted as message 541.

2006
error
no hexadecimal digits following \string escape sequence
A \x or \u escape sequence was seen but there were no hexadecimal digits immediately following the sequence.
Supports MISRA C 2004 Rule 4.1 - Only those escape sequences that are deﬁned in the ISO C standard shall be used.

2400
warning
unexpected internal condition 'string'
PC-lint Plus has encountered an unexpected situation while processing the provided source code. This doesn’t necessarily represent either a bug in the source code or in PC-lint Plus, and PC-lint Plus will continue to operate normally, but rather serves to report potentially interesting circumstances that may be of use to Vector Informatik GmbH engineering staﬀ. This message is not emitted unless appropriate debugging options are enabled.

2401
warning
cannot mix positional and non-positional arguments in format string
The format string for a printf/scanf style function contains both positional and non-positional arguments. Positional arguments are an extension provided by POSIX implementations but mixing positional and non-positional arguments results in undeﬁned behavior. For example:

printf("%1$d %d", 1, 2);

will elicit this message.
Supports CERT C FIO47-C - Use valid format strings
Supports CWE-134 - Use of Externally-Controlled Format String
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports CWE-686 - Function Call With Incorrect Argument Type

2402
warning
'string' speciﬁed ﬁeld string is missing a matching 'int' argument
The format string for a printf/scanf style function contains a conversion speciﬁer whose width or precision is given as an asterisk (*) indicating that the width/precision be extracted from the next argument, which should have type int, but this argument was not provided.
Supports CERT C FIO47-C - Use valid format strings
Supports CWE-134 - Use of Externally-Controlled Format String
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports CWE-686 - Function Call With Incorrect Argument Type
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2403
warning
ﬁeld string should have type type, but argument has type type
The width or precision of a conversion speciﬁer within the format for a printf or scanf style function was speciﬁed with an asterisk (*) and as such a corresponding int argument was expected to represent the width/precision but the argument in that position was not the correct type. For example:

extern double f; 
printf("%*d", f, f);

will yield the messages:

field width should have type 'int', but argument has type 'double'

Supports CERT C INT00-C - Understand the data model used by your implementation(s)
Supports CERT C FIO47-C - Use valid format strings
Supports CWE-134 - Use of Externally-Controlled Format String
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports CWE-686 - Function Call With Incorrect Argument Type

2404
warning
invalid position speciﬁed for string
Within the format string of a printf or scanf style function, a positional parameter speciﬁer was expected for a ﬁeld width or precision that used the asterisk (*) to indicate that the ﬁeld or width should be taken from the argument list but one was not provided. For example:

printf("%1$*d", 1, 2);

will yield the message:

invalid position specified for field width

This is because when positional speciﬁers are used within a format string, all arguments must have corresponding positional speciﬁers. The correct way to indicate that the ﬁeld width corresponds to the second data argument is:

printf("%1$*2$d", 1, 2);

2405
warning
string used with 'string' conversion speciﬁer is undeﬁned
The use of a ﬁeld width or precision with an incompatible conversion speciﬁer has been encountered. Standard C allows a precision to be used only with the d, I, o, u, x, X, a, A, e, E, f, F, g, and G conversion speciﬁers and a ﬁeld width to be used with any conversion speciﬁers except for n. Use of ﬁeld width/precision outside of these conversion speciﬁers results in undeﬁned behavior.
Supports CERT C FIO47-C - Use valid format strings
Supports CWE-134 - Use of Externally-Controlled Format String
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports CWE-686 - Function Call With Incorrect Argument Type
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2406
warning
no closing ']' for '%[' in scanf format string
Within a format string for a scanf style function, a ’%[’ was seen denoting the start of a scan list but there was no terminating ’]’. The lack of a closing bracket makes the conversion speciﬁcation invalid and results in undeﬁned behavior.
Supports CERT C FIO47-C - Use valid format strings
Supports CWE-134 - Use of Externally-Controlled Format String
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports CWE-686 - Function Call With Incorrect Argument Type

2407
warning
zero ﬁeld width in scanf format string is unused
Within a scanf style function, a zero was given as the maximum ﬁeld width. Standard C speciﬁes that the maximum ﬁeld width for scanf must be a "decimal integer greater than zero". Providing a zero as the width makes the conversion speciﬁer invalid resulting in undeﬁned behavior.
Supports CERT C FIO47-C - Use valid format strings
Supports CWE-134 - Use of Externally-Controlled Format String
Supports CWE-685 - Function Call With Incorrect Number of Arguments
Supports CWE-686 - Function Call With Incorrect Argument Type

2408
warning
cannot pass string object of type type to variadic string; expected type from format string was type
A non-POD or non-trivial class type that cannot be passed as a variadic function argument was given as the argument to a printf/scanf style function. The ﬁrst type speciﬁes the type of the argument that was provided, the second type speciﬁes the type that was expected from the format string.
Supports CERT C DCL11-C - Understand the type issues associated with variadic functions

2410
warning
re-entrant initializer for static local variable symbol causes undeﬁned behavior
Recursively executing the initializer for a static local variable is undeﬁned behavior, even if it appears not to cause an inﬁnite loop. An implementation with proper support for thread-safe static initialization is likely to deadlock.
Supports CWE-833 - Deadlock

2414
warning
non-standard literal suﬃx 'string'
This message is issued when a non-standard, non-user-deﬁned, numeric literal suﬃx that is recognized by PC-lint Plus is encountered. The use of non-standard literal suﬃxes is not portable. The suﬃxes reported by this message include q/Q, I8/I16/I32/I64 (and the lowercase equivalents), NaN and Infinity.

2415
warning
loop comparison value 'integer' out of range for operator 'string'
A comparison was seen in a loop condition between a loop invariant integer tracked by Introduction and another expression that was determined to be out of range as described in Precision, Viable Bit Patterns, and Representable Values. This message is not issued when the comparison involves a constant expression (see 587 , 650 , and 685 ) or for expressions that are not for or while conditions (see 696 ).

2416
warning
generic selection association type type will never be eligible for selection
A generic selection was encountered with an association whose type will never be eligible for selection. When types are checked against the association list, top level qualiﬁers on objects are removed and both arrays and function values are decayed into pointers. Therefore, providing an association for them is not useful and is almost certainly an error. Associations that are not selectable include: a const-qualiﬁed object type, a volatile-qualiﬁed object type, a restrict-qualiﬁed object type, an atomic object type, an array type, a function type, and a structure or union deﬁnition.
Supports MISRA C 2012 AMD3 Rule 23.4 - A generic association shall list an appropriate type
Supports MISRA C:2023 Rule 23.4 - A generic association shall list an appropriate type
Supports MISRA C:2025 Rule 23.4

2417
warning
'string' qualiﬁer on function type type
A function type was speciﬁed with const or volatile. Specifying a function with type qualiﬁers in C will result in undeﬁned behavior. In C++ type qualiﬁers are ignored. For example:

typedef int ftype (void); 
const   ftype cfunc; // Warning 2417 
volatile ftype vfunc; // Warning 2417

Supports MISRA C 2012 AMD3 Rule 17.13 - A function type shall not be type qualiﬁed
Supports MISRA C:2023 Rule 17.13 - A function type shall not be type qualiﬁed
Supports MISRA C:2025 Rule 17.13

2418
warning
declaration of symbol symbol with strong type 'strong-type' conﬂicts with previous declaration with strong type 'strong-type'
A strong type conﬂict was detected when comparing the strong types (or lack thereof) in a redeclaration to those in the original declaration earlier in the module. Note that such a conﬂict is not subject to softeners.

2419
warning
controlling expression contains a side eﬀect which will not be evaluated
The controlling expression of a generic-selection has a side eﬀect. The controlling expression is never evaluated and is only used for its type. Thus, side eﬀects are not applied, even if the expression has a type that would cause it to be evaluated by sizeof such as a VLA. The related message 9213 will report controlling expressions containing function calls. For example:

int x = 0; 
int foo() { return 0; } 
_Generic(x++,  int: 1, default: 0); // Warning 2419 
_Generic(foo(), int: 1, default: 0); // Note 9213

This message is not emitted when the controlling expression is expanded from a macro argument.
Supports MISRA C 2012 AMD3 Rule 23.2 - A generic selection that is not expanded from a macro shall not contain potential side eﬀects in the controlling expression
Supports MISRA C:2023 Rule 23.2 - A generic selection that is not expanded from a macro shall not contain potential side eﬀects in the controlling expression
Supports MISRA C:2025 Rule 23.2

2420
warning
ignoring return value of function symbol declared with attribute 'string'
The return value of a function marked with a nodiscard or warn_unused_result attribute was ignored. For example:

[[nodiscard]] extern int func1(); 
extern int func2() __attribute__((warn_unused_result)); 
 
func1();   //warning 2420 
func2();   //warning 2420 
 
int result1 = func1();   //no warning 
int result2 = func2();   //no warning

Like 534 , casting the unused return value to void will suppress the message.

2421
warning
unsigned wrap-around in computing type constant for 'operator'
Unsigned integer wrap-around occurred while computing a constant expression. For example,

   unsigned int n = 0U - 1U;

will result in a wrap-around to the largest unsigned int value.
Supports MISRA C 2012 Rule 12.4 - Evaluation of constant expressions should not lead to unsigned integer wrap-around
Supports MISRA C:2023 Rule 12.4 - Evaluation of constant expressions should not lead to unsigned integer wrap-around
Supports MISRA C:2025 Rule 12.4

2423
warning
apparent domain error for function symbol, argument integer (value=string) outside of accepted range (string)
A value was provided to a mathematical function that will result in a domain error. For example, the acos function is only deﬁned for values in the range [-1, 1], values provided outside this range will be diagnosed by this message. Value tracking is used to determine the value provided to the function. For example:

double foo(double x, double y) { 
   acos(x + y); 
} 
void bar() { 
   foo(0.5, 0.75); 
}

will elicit the message:

warning 2423: apparent domain error for function 'acos(double)', 
   argument 1 (value=1.25) outside of accepted range (between -1 and 1) 
acos(x + y); 
      ^

Supports AUTOSAR19 Rule A0-4-4
Supports CERT C FLP32-C - Prevent or detect domain and range errors in math functions
Supports CWE-391 - Unchecked Error Condition
Supports CWE-682 - Incorrect Calculation
Supports CWE-687 - Function Call With Incorrectly Speciﬁed Argument Value
Supports MISRA C 2004 Rule 20.3 - The validity of values passed to library functions shall be checked.
Supports MISRA C 2012 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2023 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2025 Dir 4.11

2425
warning
user-deﬁned function semantic 'string' was rejected during call to function symbol because string
A call was made to a function for which a user-deﬁned semantic exists but the semantic could not be applied because it contains a semantic that is not valid for this call. There are several reasons this can occur including specifying a semantic for an argument that does not exist, a return value of a type that conﬂicts with the actual return value, or the use of a symbol or macro in the semantic that cannot be resolved at the time of the call.

2426
warning
return value (string) of call to function symbol conﬂicts with return semantic 'string'
A user-deﬁned return semantic was speciﬁed for a function for which PC-lint Plus has access to the implementation. Furthermore, PC-lint has determined that during a speciﬁc call of the function the actual value returned conﬂicts with the claimed return value in the return semantic. This represents a likely error in either the implementation of the function or the speciﬁcation of the semantic. See also 9.2.2.2 Return Semantic Validation in the Semantics chapter.

2427
warning
initializer_list elements will be destroyed before returning
The array associated with an initializer list is allocated with a temporary lifetime. The lifetime of the array will not be extended beyond the full expression of a return statement. The returned initializer list will contain dangling pointers. For example:

#include <initializer_list> 
 
std::initializer_list<int> f() { 
   return { 1, 2, 3 }; // The memory used to store the array 
                    // elements will be freed before returning. 
} 
 
void g() { 
   auto x = f(); 
   // Attempting to access the elements of x will read invalid memory. 
}

Note that this message will be issued when returning a local variable of initializer_list type (regardless of initialization source), including a parameter. While it may initially appear safe to return an initializer_list argument as the lifetime was determined by the caller, this is likely to lead to invalid use of the return value in the caller when a temporary argument is destroyed at the end of the statement of the call expression.

2430
warning
missing whitespace between macro name name and deﬁnition
Standard C requires the presence of whitespace between a macro name and its deﬁnition for object-like macros. For example:

#define MINUS-

will elicit:

warning 2430: missing whitespace between macro name 'MINUS' and definition 
#define MINUS- 
           ^

Despite the warning, the macro MINUS is still deﬁned to - so it is safe to suppress this message for legacy code that cannot be changed. The best way to address the warning is to place a space between the macro name and deﬁnition:

#define MINUS -

2431
warning
#line/GNU line directive starting with zero is not interpreted as an octal number
The line number provided to the #line number preprocessing directive (and the GNU equivalent # number) is always interpreted as a decimal number, even when the ﬁrst digit is a zero. For example, #line 034 is treated as #line 34, not as #line 28 (the decimal equivalent of octal 34). As such, a #line directive with a line number beginning with a zero is suspicious.

2432
warning
macro name used as header guard is followed by a #deﬁne of a similar but diﬀerent macro 'name'
Within a construct that appears to be a macro include guard, the name of the macro being checked is similar to, but diﬀerent from, the name of the macro subsequently deﬁned. For example:

#ifndef FOO_INCLUDED 
#define FOO_INCLODED 
... 
#endif

will elicit:

warning 2432: macro 'FOO_INCLUDED' used as header guard is followed by a 
   #define of a similar but different macro 'FOO_INCLODED' 
#ifndef FOO_INCLUDED 
      ^~~~~~~~~~~~

This usually represents a typo, which will prevent the include guard from functioning as intended. This message can be suppressed with -estring using the name of the macro being deﬁned, e.g. -estring(2432, FOO_INCLODED) if the diﬀerence was intentional.

2433
warning
conversion speciﬁer 'string' is not allowed for bounds-checked format function
Bounds-checked format functions are described in Annex K of the C11 standard. The bounds-checked printf-like functions forbid the use of the %n conversion speciﬁer.

2434
warning
memory was potentially deallocated
This message is a less certain variant of 449 and is issued when the deallocation was dependent on conditional execution ﬂow at runtime.
Supports CERT C MEM00-C - Allocate and free memory in the same module, at the same level of abstraction
Supports CERT C MEM30-C - Do not access freed memory
Supports CWE-415 - Double Free
Supports CWE-416 - Use After Free
Supports CWE-666 - Operation on Resource in Wrong Phase of Lifetime
Supports CWE-672 - Operation on a Resource after Expiration or Release
Supports CWE-758 - Reliance on Undeﬁned, Unspeciﬁed, or Implementation-Deﬁned Behavior
Supports CWE-825 - Expired Pointer Dereference
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Dir 4.13
Supports MISRA C:2025 Rule 1.3

2435
warning
duplicate 'string' declaration speciﬁer
The same declaration speciﬁer was used more than once in the declaration of a symbol. For example:

inline inline void foo();

will elicit this message. Was this intended? While legal, it is suspect. Other speciﬁers that will be diagnosed for duplicates include virtual, explicit, _Noreturn, friend, and constexpr.

2436
warning
function symbol declared 'noreturn' should not return
A function that was declared as not returning either with the keyword _Noreturn or a GCC or C++11 noreturn attribute contained a return statement. Returning from a function designated as not returning invokes undeﬁned behavior.
Supports AUTOSAR19 Rule A7-6-1
Supports MISRA C 2012 AMD3 Rule 17.9 - A function declared with a _Noreturn function speciﬁer shall not return to its caller
Supports MISRA C:2023 Rule 17.9 - A function declared with a _Noreturn function speciﬁer shall not return to its caller
Supports MISRA C:2025 Rule 17.9
Supports MISRA C++:2023 Rule 9.6.4 - A function declared with the [[noreturn]] attribute shall not return

2437
warning
indirection of non-volatile null pointer may be optimized out
An indirection on a non-volatile null pointer was encountered. While this is undeﬁned behavior as far as Standard C is concerned, the programmer may have intended for this to generate a trap condition relying on implementation details but the compiler is likely to simply remove the oﬀending indirection instead. The null pointer should be volatile to indicate to the compiler that it should not be optimized out.

2438
warning
comparing values of diﬀerent enumeration types (type and type)
The values of two diﬀerent enumeration types were used in an equality or comparison operation. This is suspect because there is no intrinsic relationship among diﬀerent enumeration types and as such it usually doesn’t make sense to compare them. For example:

enum color { RED, GREEN, BLUE }; 
enum fruit { APPLE, PEAR, MANGO }; 
 
void foo(enum color c, enum fruit f) { 
   if (c == f) return;    // 2438 issued here 
   // ... 
}

The message is parameterized by the two enumeration types compared.

2439
warning
lint comment does not contain any options
A lint comment was encountered that did not contain any lint options, was this a mistake? The comment may be empty or may start with text that does not begin an option. For example:

//lint e714 -e715

Since e714 does not start with a -, +, or !, it, along with everything that follows, is assumed to be commentary. In this case -e714 was probably meant.

2440
warning
string 'string' in comparison is never null
The address of a function, array, or variable was directly compared to null. This is suspicious because the address of a function or variable can never be null in well-formed code. Note that this message is not given for null checks of function or object pointers. For example:

void foo(int *pi) { 
   if (!pi) return;       // Okay 
   if (&pi == 0) return;  // 2440 
   if (foo != 0) return;  // 2440 
}

The ﬁrst string parameter is one of ’function’, ’array’, or ’address of’ and the second string parameter represents the corresponding function, array, or variable.
Supports CERT C EXP16-C - Do not compare function pointers to constant values

2441
warning
string 'string' used in boolean context is never null
The address of a function, array, or variable was used in a boolean context. This is suspicious because such an address can never be false. Note that this message is not given for function or object pointers. For example:

void foo(int *pi) { 
   if (!pi) return;   // Okay 
   if (&pi) return;   // 2441 
   if (!foo) return;  // 2441 
}

2444
warning
case value is not in enumeration type
The condition of a switch statement has enum type but contains a case statement with a value that doesn’t correspond to any of the enumerators in the enum. For example:

enum color { RED, GREEN, BLUE }; 
void foo(enum color c) { 
   switch (c) { 
   case RED:      // OK 
   case RED + 1:  // OK, refers to GREEN 
   case 2:       // OK, refers to BLUE 
   case 3: ...    // Warning 2444, no member with value 3 
   } 
}

2445
warning
cast from type to type increases required alignment from integer to integer
A cast was made from a pointer to one type to a pointer to a type that has greater alignment requirements than the type pointed to by the original pointer. For example, assuming an alignment requirement of 4 bytes for ’int’ and 8 bytes for ’long double’:

void foo(int *pi) { 
   long double *pld = (long double *)pi; 
}

will result in the message:

warning 2445: cast from 'int *' to 'long double *' increases 
   required alignment from 4 to 8 
long double *pld = (long double *)pi; 
                ^~~~~~~~~~~~~~~~~

Accessing the value through the new pointer may invoke undeﬁned behavior if it is not properly aligned. The alignment requirements of fundamental types can be set using the -a option.

The message is parameterized by the types of the pointer before and after the cast and the alignment requirements of the types before and after the cast.
Supports CERT C EXP36-C - Do not cast pointers into more strictly aligned pointer types
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2446
warning
pasting formed 'string', an invalid preprocessing token
During a token pasting operation performed by the preprocessor ## operator, an invalid token was formed. This is illegal even if the result is immediately pasted with another token that would then form a valid token. For example, a naive token concatenation macro might look like:

CAT(x, y) x##y

which would work ﬁne in cases like int i = CAT(1,2); and expand to int i = 12; without issue. The problem comes about when the macro is invoked recursively, such as:

int i = CAT(CAT(1, 2), 3);

which will be greeted with:

warning 2446: pasting formed ')3', an invalid preprocessing token 
int i = CAT(CAT(1, 2),3); 
      ^ 
supplemental 893: expanded from macro 'CAT' 
#define CAT(x,y) x##y 
               ^

followed by other parsing errors. One way to handle this is to use two macros:

#define CATX(x, y) x##y 
#define CAT(x, y) XCAT(x, y)

2447
warning
'main' function should not be declared as 'string'
This message is issued when the main function is declared as static, inline, constexpr, or deleted. The C++ Standard forbids the main function to be declared with these speciﬁers.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2448
warning
'main' function should return type 'int'
According to the C Standard, the main function must return int in a hosted environment but a return type other than int was speciﬁed for main. If you are targeting a freestanding/embedded platform or making use of non-standard extensions, you should suppress this message.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2449
warning
string discards qualiﬁers

2450
warning
null character ignored
A literal null character was encountered within the module being processed and will be ignored by PC-lint Plus.

2452
warning
string converts between pointers to integer types string
A pointer to an signed integer type was implicitly converted to or from a pointer to the corresponding unsigned integer type. For example:

void foo(int *p) { 
   unsigned *up = p;  // Warning 2452 
}

Supports CWE-135 - Incorrect Calculation of Multi-Byte String Length
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2453
warning
incompatible pointer to integer conversion string string
A pointer type was implicitly converted to an incompatible integer type. For example:

void foo(float *p) { 
   int i = p;  // Warning 2453 
}

2454
warning
incompatible pointer types string string
A pointer type was implicitly converted to an incompatible pointer type. For example:

void foo(float *pf) { 
   int *pi = pf;  // Warning 2454 
}

Supports CERT C STR38-C - Do not confuse narrow and wide character strings and functions
Supports CWE-135 - Incorrect Calculation of Multi-Byte String Length
Supports MISRA C 2004 Rule 1.2 - No reliance shall be placed on undeﬁned or unspeciﬁed behaviour.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2455
warning
incompatible function pointer types string string
A function pointer type was implicitly converted to an incompatible function pointer type. For example:

void foo(int i) { 
   int (*pf)(float) = &foo;   // Warning 2455 
}

2456
warning
C++ language linkage speciﬁcation encountered in C mode
A C++ language linkage speciﬁcation was encountered in a C module. For example:

extern "C++" int i;

This may indicate that a C++ module is incorrectly being processed in C mode or that a region of code that is only intended to be processed in C++ is not properly guarded (e.g. with #ifdef __cplusplus). Language linkage speciﬁcations in C mode are supported by some embedded compilers. If your compiler supports this, feel free to suppress this message.

2457
warning
non-recursive mutex 'name' locked recursively in function 'name' of thread 'name' at location
While processing the call graph during Thread Analysis , PC-lint Plus detected multiple lock attempts of a non-recursive mutex without an intervening unlock operation. The lock attempts may occur within a single function or may span multiple functions (possibly in diﬀerent modules) or involve recursive calls into a function. Attempting to lock a non-recursive mutex multiple times will result in a deadlock in most mutex implementations. Supplemental messages provide the call path from the thread root function to the point where the mutex was locked recursively.

This message is suppressed if inter-module thread analysis is disabled (see Inhibition of Thread Analysis ).
Supports CWE-833 - Deadlock
Supports MISRA C 2012 AMD4 Rule 22.18 - Non-recursive mutexes shall not be recursively locked
Supports MISRA C:2023 Rule 22.18 - Non-recursive mutexes shall not be recursively locked
Supports MISRA C:2025 Rule 22.18

2460
warning
string literal string provided as argument integer to function symbol
A string, character, integer, or ﬂoating literal was provided as an argument to a function parameter which was designated with the noliteral argument semantic indicating that the argument should not be a literal. For example, perhaps a database connection function should not receive a string literal in the password argument ﬁeld.
Supports CERT C MSC32-C - Properly seed pseudorandom number generators
Supports CERT C MSC41-C - Never hard code sensitive information
Supports CWE-798 - Use of Hard-coded Credentials
Supports MISRA C 2004 Rule 20.3 - The validity of values passed to library functions shall be checked.
Supports MISRA C 2012 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2023 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2025 Dir 4.11

2461
warning
'rand/random' function used without any explicit call to 'srand/srandom'
This message is issued at the conclusion of global wrap-up if a call to the standard rand or POSIX random function was found in the program but no call to the corresponding seed function srand or srandom was found.
Supports CERT C MSC32-C - Properly seed pseudorandom number generators
Supports CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
Supports CWE-330 - Use of Insuﬃciently Random Values
Supports CWE-331 - Insuﬃcient Entropy
Supports CWE-337 - Predictable Seed in Pseudo-Random Number Generator (PRNG)
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2025 Dir 4.13

2462
warning
mutexes 'name' and 'name' have lock order mismatch in function 'name' of thread 'name' at location and function 'name' of thread 'name' at location
The speciﬁed mutexes are locked in diﬀerent orders in diﬀerent call paths (possibly spanning diﬀerent modules). The call path from each thread root to the conﬂicting lock orders are provided as supplemental messages as are the ﬁnal lock orders within each thread. Inconsistent order of mutex acquisition can result in deadlocks between threads.

This message is suppressed if inter-module thread analysis is disabled (see Inhibition of Thread Analysis ).
Supports CERT C CON35-C - Avoid deadlock by locking in a predeﬁned order
Supports CWE-833 - Deadlock
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C 2012 AMD4 Dir 5.2 - There shall be no deadlocks between threads
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Dir 5.2 - There shall be no deadlocks between threads
Supports MISRA C:2025 Dir 4.13
Supports MISRA C:2025 Dir 5.2

2463
warning
'string' statement while locked
A goto or label statement (indicated by string) was encountered while a mutex was locked. The use of goto is best avoided while holding a mutex as doing so presents an entire class of potential issues. Processing will continue ignoring the goto or label statement for the purpose of thread analysis. If a goto jumps to a point with a diﬀerent mutex lock state (e.g. jumps over a mutex lock or unlock operation), the corresponding thread analysis may be incorrect. This message may be safely suppressed in cases where jumps do not traverse such operations. This message is accompanied by one or more supplemental messages providing the locations at which the currently held mutexes were locked.

2465
warning
redeﬁnition of tag type will not be visible outside of this function
A tag that was previously deﬁned is being redeﬁned in a function parameter list. While this is legal, it is suspect as this redeﬁnition will only be visible within the function. It would be better to use another name and/or place the desired deﬁnition outside the function if the intention is to make the tag visible elsewhere.

2466
warning
symbol was used despite being marked as 'unused'
The speciﬁed symbol was used despite being marked as unused, either via #pragma unused, the GCC __attribute__ syntax, or with a C++11-style attribute speciﬁed. For example:

int i = 1; 
#pragma unused(i) 
int j [[gnu::unused]] = 2; 
int k __attribute__((unused)) = 3;

Message 2466 will be issued if i, j, or k are subsequently used.

2467
warning
multiple deﬁnitions of function symbol
Multiple deﬁnitions of the speciﬁed function were found which would impair thread analysis as PC-lint Plus does not know which deﬁnition to use. A link error would presumably occur during compilation of the program as well.

Attempted issuance of this message will disable inter-module thread analysis (see Inhibition of Thread Analysis ).

See message 2469 for multiple variable deﬁnitions.
Supports AUTOSAR17 Rule M3-2-4
Supports AUTOSAR19 Rule M3-2-4
Supports MISRA C 2004 Rule 8.9 - An identiﬁer with external linkage shall have exactly one external deﬁnition.
Supports MISRA C 2012 Rule 8.6 - An identiﬁer with external linkage shall have exactly one external deﬁnition
Supports MISRA C:2023 Rule 8.6 - An identiﬁer with external linkage shall have exactly one external deﬁnition
Supports MISRA C:2025 Rule 8.6
Supports MISRA C++:2008 Rule 3-2-4 - An identiﬁer with external linkage shall have exactly one deﬁnition.
Supports MISRA C++:2023 Rule 6.2.1 - The one-deﬁnition rule shall not be violated

2468
warning
semantic mismatch for function symbol
The speciﬁed function was referenced in multiple modules for which either 1) diﬀerent thread names were attributed to the function via the thread or thread_mono semantic or 2) diﬀerent thread-protected statuses were speciﬁed for the function via the thread_protected semantic.

Attempted issuance of this message will disable inter-module thread analysis (see Inhibition of Thread Analysis ).

2469
warning
multiple deﬁnitions of variable symbol
A variable with external linkage has been deﬁned in multiple translation units. For example, the following global deﬁnition will be diagnosed if present in two or more translation units:

int a = 0;  // note 2469

Note that C++11 default member initializers are not considered to be deﬁnitions, and can be present in multiple modules.

Note that C++17 inline variables may be deﬁned in multiple modules. This message will be emitted if, and only if, they are deﬁned in diﬀerent locations. If the inline variable is deﬁned in the same header across the project, no diagnostic will be issued.

See message 2467 for multiple function deﬁnitions.
Supports AUTOSAR17 Rule M3-2-4
Supports AUTOSAR19 Rule M3-2-4
Supports MISRA C 2004 Rule 8.9 - An identiﬁer with external linkage shall have exactly one external deﬁnition.
Supports MISRA C 2012 Rule 8.6 - An identiﬁer with external linkage shall have exactly one external deﬁnition
Supports MISRA C:2023 Rule 8.6 - An identiﬁer with external linkage shall have exactly one external deﬁnition
Supports MISRA C:2025 Rule 8.6
Supports MISRA C++:2008 Rule 3-2-4 - An identiﬁer with external linkage shall have exactly one deﬁnition.
Supports MISRA C++:2023 Rule 6.2.1 - The one-deﬁnition rule shall not be violated

2470
warning
multiple consecutive pushbacks onto stream is not portable
A ﬁle stream was subjected to multiple consecutive pushbacks (such as by the ungetc function). Standard C guarantees support for pushing back a single character. While some implementations support pushback of multiple characters, this is non-portable.
Supports CERT C FIO13-C - Never push back anything other than one read character

2471
warning
operation on stream that has been closed
An operation was performed on a ﬁle stream that has been closed. The value of a ﬁle pointer after calling fclose is indeterminate and attempts to perform ﬁle operations in such a pointer result in undeﬁned behavior.
Supports CERT C FIO46-C - Do not access a closed ﬁle
Supports CWE-666 - Operation on Resource in Wrong Phase of Lifetime
Supports CWE-672 - Operation on a Resource after Expiration or Release
Supports CWE-758 - Reliance on Undeﬁned, Unspeciﬁed, or Implementation-Deﬁned Behavior
Supports CWE-910 - Use of Expired File Descriptor
Supports CWE-1341 - Multiple Releases of Same Resource or Handle
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C 2012 Rule 22.6 - The value of a pointer to a FILE shall not be used after the associated stream has been closed
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Rule 22.6 - The value of a pointer to a FILE shall not be used after the associated stream has been closed
Supports MISRA C:2025 Dir 4.13
Supports MISRA C:2025 Rule 22.6

2472
warning
non-standard ﬁle mode character/component 'string' in mode string 'string'
A non-standard character was encountered in the mode argument to fopen or freopen. The allowable characters are a, b, r, w, x, and +; other characters appearing in the mode argument results in undeﬁned behavior.

Supports CERT C FIO11-C - Take care when specifying the mode parameter of fopen()
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2473
warning
ﬁle mode string 'string' is not a legal ﬁle open mode: string
The mode argument in a call to fopen or freopen contained valid characters but was not one of the speciﬁc combinations allowed by Standard C and therefore will result in undeﬁned behavior. The allowed combinations are:

"r"	"w"	"wx"	"a"
"rb"	"wb"	"wbx"	"ab"
"r+"	"w+"	"w+x"	"a+"
"r+b"	"w+b"	"w+bx"	"a+b"
"rb+"	"wb+"	"wb+x"	"ab+"

The second string parameter provides an explanation of why the mode argument is invalid.

Supports CERT C FIO11-C - Take care when specifying the mode parameter of fopen()
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2474
warning
attempt to ﬂush stream that isn't open for writing
An ﬁle stream that was not opened for writing was provided as an argument to a ﬁle-ﬂushing function such as fflush. Attempting to ﬂush a ﬁle stream that wasn’t opened for writing (or update) results in undeﬁned behavior.
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2025 Dir 4.13

2475
warning
attempt to ﬂush stream after an input operation
An attempt was made to ﬂush a ﬁle stream immediately following an input operation; this results in undeﬁned behavior.
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Dir 4.13
Supports MISRA C:2025 Rule 1.3

2476
warning
attempt to perform read operation on stream not opened for reading
An attempt was made to read from a ﬁle stream that was not opened for reading. This results in undeﬁned behavior.
Supports CWE-910 - Use of Expired File Descriptor
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2025 Dir 4.13

2477
warning
attempt to perform write operation on stream not opened for writing
An attempt was made to write to a ﬁle stream that was not opened for writing. This results in undeﬁned behavior.
Supports CWE-910 - Use of Expired File Descriptor
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C 2012 Rule 22.4 - There shall be no attempt to write to a stream which has been opened as read-only
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Rule 22.4 - There shall be no attempt to write to a stream which has been opened as read-only
Supports MISRA C:2025 Dir 4.13
Supports MISRA C:2025 Rule 22.4

2478
warning
attempt to perform read operation on stream after write without an intervening ﬂush or reposition
An attempt was made to read from a ﬁle stream following a write operation on the stream. Failure to ﬂush or reposition the stream between a write and subsequent read operation results in undeﬁned behavior.
Supports CERT C FIO39-C - Do not alternately input and output from a stream without an intervening ﬂush or positioning call
Supports CWE-664 - Improper Control of a Resource Through its Lifetime
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Dir 4.13
Supports MISRA C:2025 Rule 1.3

2479
warning
attempt to perform write operation on stream after read without an intervening reposition
An attempt was made to write to a ﬁle stream following a read operation on the stream. Failure to reposition the stream between a read and subsequent write operation results in undeﬁned behavior.
Supports CERT C FIO39-C - Do not alternately input and output from a stream without an intervening ﬂush or positioning call
Supports CWE-664 - Improper Control of a Resource Through its Lifetime
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Dir 4.13
Supports MISRA C:2025 Rule 1.3

2480
warning
attempt to perform byte-oriented operation on stream following wide-stream operation
A byte-oriented ﬁle manipulation function was called with a wide-oriented ﬁle stream which results in undeﬁned behavior.
Supports CERT C STR38-C - Do not confuse narrow and wide character strings and functions
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2481
warning
attempt to perform wide-oriented operation on stream following byte-stream operation
A wide-oriented ﬁle manipulation function was called with a byte-oriented ﬁle stream which results in undeﬁned behavior.
Supports CERT C STR38-C - Do not confuse narrow and wide character strings and functions
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2482
warning
enumeration constant 'name' not deﬁned
This message is issued when a call to mtx_init is seen without a deﬁnition for mtx_recursive or a call to mtx_trylock is seen without a deﬁnition for thrd_success. Without knowing the value of mtx_recursive, PC-lint Plus will not be able to determine whether the mutex being initialized by mtx_init is recursive. Without a deﬁnition for thrd_success, PC-lint Plus will not be able to infer the lock status of the mutex after a call to mtx_trylock.

2483
warning
invalid semantics for 'name', string
This message is issued when invalid function thread semantics are speciﬁed using the -sem option. This can occur if a semantic is employed that requires additional semantics to be speciﬁed which were missing or if multiple conﬂicting semantic options are speciﬁed.

The name parameter contains the name of the function speciﬁed in the oﬀending semantic and the string parameter contains additional information about the invalid nature of the semantic.

For example:

-sem(foo, thread, thread_unsafe)

will elicit:

warning 2483: invalid semantics for ’foo’, thread_unsafe incompatible with thread

since it does not make sense for a function to have both the thread semantic and the thread_unsafe semantic.

None of the semantics speciﬁed in the reported -sem option will be applied.

2484
warning
invalid semantics for argument string of 'name', string
An invalid mutex/thread argument semantic was provided. For example:

-sem(f, locker_lock, mutex_locker(1), mutex_locker(2))

will elicit:

warning 2484: invalid semantics for argument 2 of ’f’, too many mutex_locker

because only one argument of a function can be designated as a mutex_locker. None of the semantics speciﬁed in the reported -sem option will be applied. This message is similar to 2483 but reports on function argument semantics.

Note that the combination of semantics that contribute to the invalid collective need not appear in the same option. For example:

-sem(f, locker_lock, mutex_locker(1))
-sem(f, mutex_locker(2))

will elicit message 2484 for the second -sem option. In this case, only the semantic speciﬁed in the second -sem option will be ignored (not applied).

2485
warning
invalid semantics for locker class symbol, string
A class was designated as a locker class using the -sem option. A property of the class (speciﬁed in the string parameter) makes it ineligible to be a locker class. The value of the string parameter is one of:

has copy constructor
has copy assignment operator
no valid constructor
no destructor
has bad move constructor

This message is issued the ﬁrst time a call to any member function of the class is encountered. Supplemental messages will communicate the member functions whose locker semantics will be removed.

2486
warning
invalid semantics for symbol, string
Invalid thread function argument semantics were detected for the speciﬁed function. The possible values of the string parameter and their corresponding meanings are:

missing mutex_attribute
A mutex_attribute_destroy, mutex_attribute_initialize, or mutex_attribute_set semantic was speciﬁed for the function without a corresponding requisite mutex_attribute semantic.
missing mutex_is_recursive, mutex_is_shared, or mutex_attribute
The mutex_initialize semantic was speciﬁed for the function without also specifying at least one of the mutex_is_recursive, mutex_is_shared, or mutex_attribute semantics.
missing mutex_locker
A locker class semantic requiring one or two mutex_locker argument semantics was speciﬁed without the requisite number of mutex_locker semantics.
missing mutex or mutex_remaining
A mutex_destroy, mutex_initialize, mutex_initialize_std_c, mutex_lock, mutex_lock_shared, mutex_unlock, mutex_unlock_shared, mutex_validate, or locker_create semantic was speciﬁed for the function without a corresponding requisite mutex or mutex_remaining semantic.
must be void
A thread_lock semantic was speciﬁed for a function which was not declared as returning void.
cannot be try_lock_none
One of the semantics mutex_lock, mutex_lock_shared, locker_lock, or locker_lock_shared was speciﬁed for the function which is declared as returning a non-void value. Such a function is considered to be a trylock-like function and a trylock semantic other than try_lock_none (the default) must be speciﬁed as well.

This message is issued for the ﬁrst call to the reported function within a module. Mutex/thread semantics will be removed from this function as indicated by the accompanying supplemental message.

2488
warning
mutex symbol passed more than once
The same mutex was passed multiple times (directly or indirectly via a locker object) to a locking function or locker class constructor. This will likely result in undeﬁned behavior and/or a deadlock for a non-recursive mutex and is suspicious at best for a recursive mutex.
Supports CWE-833 - Deadlock

2489
warning
exclusively locked mutex symbol is being shared locked/unlocked
A shared locking or unlocking operation is being attempted on a mutex which is already exclusively locked by the function. Attempting to share lock or unlock a std::shared_mutex is undeﬁned if the same thread holds an exclusive lock on the mutex. In other threading libraries this is likely to result in a deadlock.
Supports CWE-833 - Deadlock

2490
warning
symbolic constant 'name' not deﬁned
A call to the pthread_mutexattr_settype function was seen at a point where neither of the symbolic constants PTHREAD_MUTEX_RECURSIVE nor PTHREAD_MUTEX_RECURSIVE_NP were deﬁned with a value that PC-lint Plus could extract. At least one of these symbolic constants should be deﬁned as either an enumeration constant or an object-like macro. If deﬁned as an enumeration constant, make sure the deﬁnition is visible by PC-lint Plus (e.g. by including the appropriate header). If deﬁned as a macro, the macro deﬁnition should be an integer literal. If PTHREAD_MUTEX_RECURSIVE or PTHREAD_MUTEX_RECURSIVE_NP are deﬁned as something other than an integer literal, the ++d option can be used to override the deﬁnition to the appropriate integer literal, e.g. ++dPTHREAD_MUTEX_RECURSIVE=1. The -mutex_attr option can also be used to inform PC-lint Plus of values and bitmasks used with pthread_mutexattr_settype that indicate a recursive mutex attribute.

2491
warning
unknown expression 'string' in sizeof will evaluate to 0, use -pp_sizeof to change the value used for evaluation
A sizeof expression was encountered inside of a preprocessor conditional. Furthermore, the expression appearing within sizeof was not previously registered with the -pp_sizeof option and will evaluate to zero. See the -pp_sizeof option for more information.

2492
warning
locker symbol already locked
An attempt is being made to lock an already-locked locker class instance. For example:

#include <mutex> 
 
std::mutex m; 
 
void foo() { 
   std::unique_lock locker(m); 
   locker.lock();     // 2492 - locker already locked 
}

A supplemental message will provide the location of the previous lock.
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2025 Dir 4.13

2493
warning
locker symbol is not locked
An attempt was made to unlock a locker class instance that is not currently locked.
Supports CWE-832 - Unlock of a Resource that is not Locked
Supports MISRA C 2012 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2023 Dir 4.13 - Functions which are designed to provide operations on a resource should be called in an appropriate sequence
Supports MISRA C:2025 Dir 4.13

2494
warning
mutex symbol is not locked
A locker class was constructed in a way that requires a locked mutex but a mutex that was not locked by the current function was provided instead. For example:

#include <mutex> 
 
std::mutex m; 
 
void foo() { 
   std::lock_guard guard(m, std::adopt_lock); 
}

The std::lock_guard constructor taking std::adopt_lock causes the lock guard to take ownership of an already aquired lock but m was not locked prior to constructing guard which results in undeﬁned behavior.

2495
warning
mutex symbol is not locked|unlocked
A mutex was passed as an argument to a function with either the mutex_must_be_locked or mutex_must_be_unlocked semantic but PC-lint Plus was able to determine that the mutex being passed was not in the correct lock state expected by the function.
Supports MISRA C 2012 AMD4 Rule 22.17 - No thread shall unlock a mutex or call cnd_wait() or cnd_timedwait() for a mutex it has not locked before
Supports MISRA C:2023 Rule 22.17 - No thread shall unlock a mutex or call cnd_wait() or cnd_timedwait() for a mutex it has not locked before
Supports MISRA C:2025 Rule 22.17

2496
warning
locker symbol is not locked|unlocked
A locker class object was passed as an argument to a function with either the mutex_must_be_locked or mutex_must_be_unlocked semantic but PC-lint Plus was able to determine that the locker being passed was not in the correct lock state expected by the function.

2498
warning
comparison of object representations of ﬂoating point values of member symbol of type type may produce unexpected results that diﬀer from a value equality test
Bitwise comparison of structures containing ﬂoating point values leads to the comparison of the object representations of data members of ﬂoating point type. See 2499 .
Supports AUTOSAR17 Rule M3-9-3
Supports AUTOSAR19 Rule M3-9-3
Supports CERT C FLP37-C - Do not use object representations to compare ﬂoating-point values
Supports MISRA C++:2008 Rule 3-9-3 - The underlying bit representations of ﬂoating-point values shall not be used.

2499
warning
comparison of object representations of ﬂoating point values of type type may produce unexpected results that diﬀer from a value equality test
Bitwise comparison of the object representations of ﬂoating point values may diﬀer in a number of ways from value comparison using comparison operators. Common diﬀerences include inequality of representations of zero and negative zero and equality of identical NaN representations (but inequality of NaNs with diﬀerent payload bits).
Supports AUTOSAR17 Rule M3-9-3
Supports AUTOSAR19 Rule M3-9-3
Supports CERT C FLP37-C - Do not use object representations to compare ﬂoating-point values
Supports MISRA C++:2008 Rule 3-9-3 - The underlying bit representations of ﬂoating-point values shall not be used.

2501
warning
negation of value of unsigned type type yields a value of signed type type due to integral promotion
An unsigned integer type was promoted to a signed type as an operand to the unary minus operator. This may surprise those who are otherwise familiar with the common adage that applying unary minus to an unsigned type does not yield a negative value (see message 501 ). For example: (assuming 16-bit shorts and 32-bit ints)

-(unsigned)5; // 2^32 - 5, type is still unsigned int 
-(unsigned short)5; // -5, type is signed int

2502
warning
diﬀering alignment requirements seen for symbol (string vs string)
An externally visible object was declared with diﬀerent explicit alignment requirements. If an object with external linkage has a conﬂicting alignment requirement, the behavior is undeﬁned.
Supports MISRA C 2012 AMD3 Rule 8.15 - All declarations of an object with an explicit alignment speciﬁcation shall specify the same alignment
Supports MISRA C:2023 Rule 8.15 - All declarations of an object with an explicit alignment speciﬁcation shall specify the same alignment
Supports MISRA C:2025 Rule 8.15

2504
warning
argument of type type supplied to type-generic macro 'macro' resulting in call to function symbol should have a string type
The operand argument passed to a type-generic macro has an inappropriate type. The operand argument must have a signed, unsigned, or ﬂoating (real or complex) type. Type-generic macros from tgmath.h can support real types, complex types, or both. Passing a complex type to a macro expecting a real type results in undeﬁned behavior. Likewise, arguments of non-arithmetic types are not convertible to any of the corresponding real types deﬁned for the macros and attempting to use them is also undeﬁned behavior.

float f; 
_Complex float cf; 
atan2(f);  // OK 
atan2(&f);  // Warning 2504 
atan2(cf);  // Warning 2504

2505
warning
argument to integer constant macro 'macro' string
The argument passed to the speciﬁed integer constant macro had an inappropriate form. The argument must be an unsuﬃxed integer literal whose value does not exceed the exact-width type of the macro used. Constant expressions are also not allowed. The behavior of such arguments to integer constant macros is undeﬁned. The string parameter describes how the supplied argument is inappropriate.

INT32_C(-100); // Warning 2505 
-INT32_C(100); // OK

Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C 2012 AMD3 Rule 7.5 - The argument of an integer constant macro shall have an appropriate form
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 7.5 - The argument of an integer constant macro shall have an appropriate form
Supports MISRA C:2025 Rule 1.3
Supports MISRA C:2025 Rule 7.5

2506
warning
argument to character-handling function 'string' is not representable as an unsigned char
The argument supplied to a character-handling function or macro from <cctype> could not be determined to have a value that is representable as an unsigned char. These functions are only well speciﬁed if the supplied value is EOF or can be represented as an unsigned char. Passing a value outside of this range is undeﬁned behavior.

void foo(char c, unsigned char uc) { 
   isdigit(129371);  // warning 2506 
   isdigit(c);      // warning 2506 
   isdigit(uc);     // Okay 
}

The relevant functions are: isalnum, isalpha, isascii, isblank, iscntrl, isdigit, isgraph, islower, isprint, ispunct, isspace, isupper, isxdigit, toascii, tolower, and toupper.
Supports AUTOSAR19 Rule A21-8-1
Supports CERT C STR37-C - Arguments to character-handling functions must be representable as an unsigned char

2507
warning
assignment between overlapping objects is not well deﬁned
An object is assigned to an overlapping object. An assignment between two objects is only well deﬁned if the objects do not overlap, or if they overlap exactly and have qualiﬁed or unqualiﬁed versions of a compatible type. For example:

union { 
   short a; 
   long b; 
} u = {0}; 
 
u.a = u.b;  // Warning 2507

Related message 464 will report when there is an attempt to copy the contents of an object onto itself.
Supports AUTOSAR17 Rule M0-2-1
Supports AUTOSAR19 Rule M0-2-1
Supports MISRA C 2004 Rule 18.2 - An object shall not be assigned to an overlapping object.
Supports MISRA C 2012 Rule 19.1 - An object shall not be assigned or copied to an overlapping object
Supports MISRA C:2023 Rule 19.1 - An object shall not be assigned or copied to an overlapping object
Supports MISRA C:2025 Rule 19.1
Supports MISRA C++:2008 Rule 0-2-1 - An object shall not be assigned to an overlapping object.

2511
warning
try_lock return value was discarded
The return value of a trylock-like function was discarded. A trylock-like function is one which may fail if the lock cannot be acquired and whose return value indicates whether locking was successful. If the return value of such a function is ignored, there is no way for the program to know (or PC-lint Plus to infer) if the lock was obtained and subsequent operations that make assumptions about the success of the call may be incorrectly performed.
Supports CWE-362 - Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’)
Supports CWE-667 - Improper Locking

2512
warning
try_lock return value was modiﬁed
The result of a trylock-like function was stored but the value was later modiﬁed. For example:

#include <mutex> 
 
std::mutex m; 
 
void foo(bool b) { 
   bool result = m.try_lock(); 
   result = b; 
   if (result) { 
      m.unlock(); 
   } 
}

Since the result variable no longer represents whether the mutex was acquired, PC-lint Plus will not be able to properly associated the actions predicated on the value of result with the lock state of the mutex.
Supports CWE-362 - Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’)

2513
warning
try_lock return value was manipulated
The result of a trylock-like function was manipulated. By manipulated we mean any use that is not a direct test of its value in a way that PC-lint Plus can appropriately inference the result such as with the binary == or != operators or the ! unary operator. Assigning the value to a variable is permitted and similar manipulation of such a variable will also be reported. The value that represents the return of a trylock-like function should be tested in a direct way in order to determine whether the lock request succeeded. See also 2511 and 2512 .
Supports CWE-362 - Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’)

2520
warning
mutex attribute symbol is not initialized
An uninitialized mutex attribute was used in a call to a function with the mutex_attribute_destroy, mutex_initialize, or mutex_attribute_set semantic. By default, the relevant functions employing these semantics are the POSIX pthread functions pthread_mutexattr_destroy, pthread_rwlockattr_destroy, pthread_mutex_init, pthread_rwlock_init, and pthread_mutexattr_settype. Passing an uninitialized mutex attribute in a call to one of these functions invokes undeﬁned behavior and will impair the ability of PC-lint Plus to determine whether a mutex initialized using the mutex attribute represents a recursive mutex.

2521
warning
mutex attribute symbol is already destroyed
A mutex attribute object that has already been destroyed is being passed to a function with the mutex_attribute_destroy semantic. By default, the functions with this semantic are the POSIX pthreads functions pthread_mutexattr_destroy and pthread_rwlockattr_destroy. Attempting to use a destroyed mutex attribute in any way other than by reinitializing it via an initialization function (e.g. pthread_mutexattr_init or pthread_rwlockattr_init) invokes undeﬁned behavior.

2522
warning
mutex attribute symbol is already initialized
A function with the mutex_attribute_initialize semantic is being called with a mutex attribute argument that has already been initialized. By default, the functions with this semantic are the POSIX pthread functions pthread_mutexattr_init and pthread_rwlockattr_init. Attempting to initialize an already initialized mutex attribute object with one of these functions results in undeﬁned behavior.

2530
note
mutex 'name' has inconsistent types
A mutex was initialized as both recursive and non-recursive or as both a shared and a non-shared mutex at diﬀerent locations. The locations where the mutex is initialized are provided in supplemental messages. PC-lint Plus will assume the mutex is recursive if it is ever initialized as recursive and shared if it is ever initialized as shared.

This message is suppressed if inter-module thread analysis is disabled (see Inhibition of Thread Analysis ).

2531
note
mutex 'name' has usage incompatible with its type 'string'
The speciﬁed mutex was initialized as a non-recursive mutex but was locked recursively or was initialized as a non-shared mutex but was used with a shared lock function. The type of the mutex is provided in the string parameter and the locations at which the incompatible operations take place are provided in supplemental messages.

This message is suppressed if inter-module thread analysis is disabled (see Inhibition of Thread Analysis ).

2536
warning
illegal character encoding in string literal
Source ﬁles are expected to be encoded as UTF-8 or UTF-16 text. The provided source ﬁle was presumed to contain UTF-8 text but an invalid byte sequence was encountered inside of an unpreﬁxed string literal. Encoding errors encountered outside of string literals are reported via error 336 .

2540
warning
mutex symbol used as a locker
The speciﬁed symbol was previously employed as a mutex but is now being used as a locker. This can occur when incorrect function argument semantics have been applied.

2541
warning
indeterminable string
During thread analysis, an entity of the type speciﬁed by string was encountered in a context for which PC-lint Plus was unable to determine its identity. String is one of locker, locker state, locker tag name, mutex, mutex attribute, or thread root function. For example, this message will be issued if the thread root function provided in a call to a thread-creation function is a function pointer whose value cannot be inferred by PC-lint Plus. This message is also issued for uses of local mutexes, PC-lint Plus currently expects mutexes to have static storage duration. This message is issued for with a string value of locker state if the state of a locker object is unknown when referenced.
Supports MISRA C 2012 AMD4 Rule 22.13 - Thread objects, thread synchronization objects and thread-speciﬁc storage pointers shall have appropriate storage duration
Supports MISRA C:2023 Rule 22.13 - Thread objects, thread synchronization objects and thread-speciﬁc storage pointers shall have appropriate storage duration
Supports MISRA C:2025 Rule 22.13

2586
warning
string name is deprecated
This message is issued when a entity is encountered that has been deprecated using either the C++14 deprecated attribute or the GCC deprecated attribute syntax. The type and name of the deprecated entity are provided in the message. If the deprecation contains a reason text, this is included as an additional string parameter as the end of the message. An 891 message provides the location of the actual deprecation. For example:

[[deprecated]] void foo(); 
 
void bar() { 
   foo(); 
}

The use of foo on line 4 results in the message:

warning 2586: Function 'foo' is deprecated 
   foo(); 
   ^ 
supplemental 891: Function 'foo' was marked deprecated here 
      [[deprecated]] void foo(); 
                ^

This message is not used to report the use of entities that are deprecated with the -deprecate option, such instances are instead reported by message 586 .

2601
warning
passing address of auto variable symbol to parameter integer of function symbol
A pointer to automatic storage was passed as an argument to a function parameter with the no_ptr_to_auto semantic. Note that during a speciﬁc walk this message is not limited to local variables in the immediate function performing the call, for example:

1//lint -sem(save, no_ptr_to_auto(1)) 
2void save(int* p); 
3void g(int* x) { 
4   save(x); 
5} 
6void f(void) { 
7   int a = 5; 
8   g(&a); 
9}

will report:

4  warning 2601: passing address of auto variable 'a' to parameter 1 of 
   function 'save' 
   save(x); 
   ^ 
8  supplemental 894: during specific walk g(&(5)) 
   g(&a); 
   ^

Supports CERT C POS34-C - Do not call putenv() with a pointer to an automatic variable as the argument
Supports CWE-562 - Return of Stack Variable Address
Supports CWE-686 - Function Call With Incorrect Argument Type

2618
warning
non-type speciﬁer 'string' appears after a type
A non-type speciﬁer was provided after a type speciﬁer in a declaration. For example int inline foo(); will elicit this message. The non-type speciﬁers reported by this message are: friend, constexpr, thread_local, mutable, inline, virtual, and explicit. See also message 618 which reports storage class speciﬁers appearing after a type and message 963 which reports on const and volatile qualiﬁers before or after a type.
Supports AUTOSAR17 Rule A7-1-8
Supports AUTOSAR19 Rule A7-1-8

2623
warning
possible domain error for function symbol, argument integer (value=string) outside of accepted range (string)
Value tracking inferencing has determined that the value provided to a mathematical function is within a range that contains values that are not appropriate for the function and may result in a domain error. For example:

double foo(unsigned i) { 
   if (i <= 10) 
      acos(i); 
}

will solicit the message:

warning 2623: possible domain error for function 'acos(double)', argument 1 
  (value=0:10) outside of accepted range (between -1 and 1) 
      acos(i); 
          ^

as the valid range for the argument to acos is [-1, 1] and all that is known about the value provided is that it is between 0 and 10. To eliminate the diagnostic, the test should be corrected as in

if (i <= 1)

Supports CWE-687 - Function Call With Incorrectly Speciﬁed Argument Value
Supports MISRA C 2004 Rule 20.3 - The validity of values passed to library functions shall be checked.
Supports MISRA C 2012 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2023 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2025 Dir 4.11

2641
warning
implicit conversion of enum symbol to ﬂoating point type type
An enumeration type was implicitly converted to a ﬂoating point type. Since enumerations are always represented using integral underlying types, it is suspicious to use an enumeration value in a ﬂoating point context. This message can be suppressed by using a cast.

2650
warning
constant 'integer' out of range for 'string' portion of compound comparison operator 'string'
This message is issued when only the "greater than" or "less than" part of a "greater than or equal" or "less than or equal" compound comparison operator is out of range. For example (assuming 8-bit bytes):

1void foo(unsigned char a) { 
2   if (a == 255) { }  // Okay - 'a' could be equal to 255 
3   if (a > 255) { }   // 650  - 'a' can't be greater than 255 
4   if (a >= 255) { }  // 2650 - 'a' could be equal but not greater than 255

Message 2650 is issued on line 4 because while a could be equal to 255, it cannot be greater than 255 so the use of the >= operator is suspicious (perhaps a was intended to be compared to a diﬀerent value). See also message 650 which is issued when the provided constant is out of range for the entire comparison operator.
Supports CERT C MSC21-C - Use robust loop termination conditions

2662
warning
pointer arithmetic on pointer that may not refer to an array
This message is issued instead of 662 when a pointer that appears likely not to refer to an array is subject to integer arithmetic. Addition, subtraction, and array subscripting are considered. Referring to the value itself with the operand zero is ignored. For example:

void f(int a) { 
   int* p = &a; 
   p[0] = 0; 
   p[1] = 0;  // Warning 2662 
   p + 0; 
   p + 1;     // Warning 2662 
}

Supports CERT C ARR37-C - Do not add or subtract an integer to a pointer to a non-array object
Supports CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buﬀer
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2666
warning
expression with side eﬀects passed to unexpanded parameter integer of macro 'string': detail
This message is issued when a function-like macro is invoked with a parameter that appears as though it would have side eﬀects if it were evaluated but since the corresponding parameter is not expanded in the macro deﬁnition, no side-eﬀect will occur. E.g.:

#define DEBUG_VAL(x) 
 
int process(int i) { 
   DEBUG_VAL(++i);  // 2666 - increment doesn't occur 
   /* ... */ 
   return i; 
}

Since the parameter isn’t expanded, ++i is not evaluated and the increment does not occur which may be unexpected. If the intention is that the side-eﬀect occurs regardless of how the macro is deﬁned, the expression provoking the side eﬀect should be placed outside the macro invocation. For the purpose of this message, any expression appearing to contain a function call is considered to have side-eﬀects.

Detail is one of “parameter is not referenced in the expansion” or “parameter is only used with #/## operators”. The message can be suppressed based on the value of the detail parameter by using -estring .
Supports CERT C PRE31-C - Avoid side eﬀects in arguments to unsafe macros

2670
warning
call to async-signal-unsafe function symbol within signal-handler-category symbol
A signal handler called an async-signal-unsafe function. This is likely to cause undeﬁned behavior.
Supports CERT C SIG30-C - Call only asynchronous-safe functions within signal handlers
Supports CWE-364 - Signal Handler Race Condition
Supports CWE-479 - Signal Handler Use of a Non-reentrant Function

2671
warning
returning from exception signal handler symbol
An exception signal handler contained a return statement. This is likely to cause undeﬁned behavior.
Supports CERT C SIG35-C - Do not return from a computational exception signal handler

2701
info
variable/function symbol declared outside of header is not deﬁned in the same source ﬁle
The speciﬁed symbol was declared inside of a module but not deﬁned inside the same module. If the symbol is deﬁned in another module, it would be better to place the declaration of the symbol in a header and include that header in the modules that use the symbol.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2702
info
static symbol symbol declared in header not referenced
The named static symbol was declared in a header included by the module but was not used within the including module. If the symbol had been declared in the module itself, warning 528 would be issued instead.

2703
info
dangling else, add braces to body of parent statement to make intent explicit
A dangling else occurs when an if/else construct appears as the unbraced body of an if statement. In such cases, it may not be clear which of the if statements the else is intended to be associated with. For example:

int foo(int a, int b) { 
   if (a) 
   if (b) 
      return 1; 
   else 
      return 0; 
   return 2; 
}

Is the else statement part of the if (a) or the if (b)? In C and C++, the else is associated with the closest preceding if that it is legal to be associated with so the else in the example is associated with if (b). The message can be addressed by placing braces around the parent if (a) statement to make the intention explicit:

int foo(int a, int b) { 
   if (a) { 
      if (b) 
          return 1; 
      else 
          return 0; 
   } 
   return 2; 
}

2704
info
potentially negating the most negative number
An integer value with the potential to equal the most negative possible integer was negated. In a two’s complement representation, there is no positive equivalent to the most negative representable integer. For example:

void f(int a) { 
   if (a < 0) { 
      a = -a; 
   } 
   // Not safe to assume a is non-negative, negation of -2147483648 
   // yields the same negative value in many compilers. 
}

Supports CERT C INT08-C - Verify that all integer values are in range
Supports CERT C INT16-C - Do not make assumptions about representation of signed integers

2705
info
type qualiﬁer(s) 'string' applied to return type has/have no eﬀect
A type qualiﬁer was provided for the return type of a function but has no eﬀect. Was the intention to qualify the function, a pointee type, a reference to the type returned, or something else? For example:

const int foo();

will be met with this message as const qualiﬁer has no eﬀect in this context.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

2706
info
integer constant value does not match any enumerator in enumeration type
An integer constant is being used to assign a value to an enumeration type but the constant value does not match the value of any of the enumeration’s enumerators. For example:

enum color { RED, GREEN, BLUE }; 
 
void foo(enum color); 
void bar() { 
   enum color c1 = RED;   // Okay 
   enum color c2 = 0;     // Okay 
   enum color c3 = 3;     // 2706 
   foo(4);              // 2706 
}

The values 3 and 4 are not part of the enumeration ’color’ so 2706 will be issued in these cases.

2707
info
function symbol could be declared as 'noreturn'
The speciﬁed function has no means of returning to its caller but this information is not included in the functions declaration via either the C11 _Noreturn keyword, the C++11 noreturn attribute, or the GCC noreturn attribute. Adding this information to the declaration may help clarify the purpose of the function.
Supports MISRA C 2012 AMD3 Rule 17.11 - A function that never returns should be declared with a _Noreturn function speciﬁer
Supports MISRA C:2023 Rule 17.11 - A function that never returns should be declared with a _Noreturn function speciﬁer
Supports MISRA C:2025 Rule 17.11

2708
info
pointer to variably modiﬁed array type type used in declaration of symbol
A variable having pointer to a variably-modiﬁed array type was declared. For example,

int n = 10; 
int (*a)[n];

will produce this message. If two pointers to arrays are used in a manner that requires them to be compatible and the size speciﬁers are not the same, this will result in undeﬁned behavior. Since variably modiﬁed arrays cannot have a known size at compile time, the risk of mismatched size speciﬁers is increased.

Supports MISRA C 2012 AMD4 Rule 18.10 - Pointers to variably-modiﬁed array types shall not be used
Supports MISRA C:2023 Rule 18.10 - Pointers to variably-modiﬁed array types shall not be used
Supports MISRA C:2025 Rule 18.10

2709
info
array subscript is of type 'char'
A value of type ’char’ was used as the subscript to an array. ’char’ is a signed type on some platforms, relying on the signedness of ’char’ in this was is not wise.

2712
info
large pass-by-value parameter symbol of type type (integer bytes) for function symbol
The speciﬁed function was declared as taking a large object type by-value. It may be more eﬃcient to have the function receive a pointer or reference instead. The threshold for determining what constitutes a large object is speciﬁed using the -size option.

2713
info
large return type type (integer bytes) for function symbol
A large object type is being returned by-value from the speciﬁed function; you might want to consider returning the object by pointer or reference instead. The threshold for determining what constitutes a large object is speciﬁed using the -size option.

2715
info
token pasting of ',' and __VA_ARGS__ is a GNU extension
The token pasting operator ## appeared between a comma and the __VA_ARGS__ macro. While supported by several compilers as a mechanism by which to elide a trailing comma in a variadic macro, such a construct is technically undeﬁned and could result in diﬀerent behavior on a compiler that doesn’t support this extension. See the discussion for the frc macro for more details.

2716
info
tentative array deﬁnition for variable symbol assumed to have one element
This message is issued when a declaration for a variable of array type that acts as a tentative deﬁnition is encountered without a declared array size. A tentative deﬁnition in C is a ﬁle-scope declaration without an initializer that does not contain an extern storage class speciﬁer. If the translation unit contains no external deﬁnition for an identiﬁer, the C Standard speciﬁes that it is deﬁned with the composite type of the tentative deﬁnition(s) for that identiﬁer. In the case of an array without a size, this becomes an array with one element. This might represent an oversight in the program. If this was intentional, it would be clearer to deﬁne the array explicitly with one element.

2721
info
pointer returned from function symbol, whose value should not be modiﬁed, is assigned to pointer to non-const
A pointer returned from a function whose value should not be modiﬁed was assigned to a pointer to non-const. These include the standard library functions localeconv, getenv, setlocale, strerror, and asctime. The C Standard speciﬁes that the program shall not modify the structure or strings returned from these functions or that they may return a non-const pointer to a const buﬀer. Treating the pointers returned by these functions as pointers to a const-qualiﬁed type can provide added safety checks from errors, warnings, and elective note 9223 . For example:

char* s = strerror(0);  // info 2721 
const struct lconv* result = localeconv();  // Okay

Modiﬁcations to these values should be done on a copy of the value.
Supports CERT C ENV30-C - Do not modify the object referenced by the return value of certain functions
Supports MISRA C 2012 AMD1 Rule 21.19 - The pointers returned by the Standard Library functions localeconv, getenv, setlocale or, strerror shall only be used as if they have pointer to const-qualiﬁed type
Supports MISRA C:2023 Rule 21.19 - The pointers returned by the Standard Library functions localeconv, getenv, setlocale or, strerror shall only be used as if they have pointer to const-qualiﬁed type
Supports MISRA C:2025 Rule 21.19

2752
info
incompatible semantics for locker class symbol, corrections applied
Incompatible thread semantics were detected for one or more member functions of the speciﬁed locker class. Corrections to address the incompatible semantics are automatically applied, the details of which are provided in supplemental messages. The semantics speciﬁed for the member functions of the locker class should be reviewed and corrected as appropriate.

2753
info
mutex symbol may not be locked|unlocked
A mutex was passed as an argument to a function with either the mutex_must_be_locked or mutex_must_be_unlocked semantic but the mutex being passed may not be in the correct state expected by the function. See also message 2495 which will report cases where the mutex is known to be in the wrong lock state.

2760
info
'srand/srandom' seeded with 'time'
This message is issued to report a call to the standard srand or POSIX srandom function if the seed argument is the result of a call to the standard time function. While this is not uncommon, it is considered insecure. The current time is predictable and the poor granularity measured in seconds on typical implementations makes it easy to probe the entire window in which the application may have called the seed function. The current time can also be manipulated in a variety of ways, not only through local access but also potentially through updates from a malicious time server. The ability for an attacker to predict the sequence of pseudorandom numbers that will be generated can render various algorithms insecure.
Supports CERT C MSC32-C - Properly seed pseudorandom number generators
Supports CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
Supports CWE-330 - Use of Insuﬃciently Random Values
Supports CWE-331 - Insuﬃcient Entropy
Supports CWE-337 - Predictable Seed in Pseudo-Random Number Generator (PRNG)

2761
info
call to non-async-signal-safe function symbol within signal-handler-category symbol
A signal handler called a function that was not explicitly async-signal-safe . This could potentially lead to undeﬁned behavior.
Supports CERT C SIG30-C - Call only asynchronous-safe functions within signal handlers
Supports CWE-364 - Signal Handler Race Condition
Supports CWE-479 - Signal Handler Use of a Non-reentrant Function

2762
info
call to signal registration function symbol within signal-handler-category symbol
A signal handler called a signal registration function. This could lead to undeﬁned behavior if the signal number being registered is not the same signal that invoked this signal handler.
Supports CERT C SIG34-C - Do not call signal() from within interruptible signal handlers
Supports CWE-364 - Signal Handler Race Condition
Supports CWE-479 - Signal Handler Use of a Non-reentrant Function

2763
info
call to signal registration function symbol within signal-handler-category symbol to register itself
A signal handler called a signal registration function to register itself. This could potentially lead to undeﬁned behavior if the signal number being registered is not the same signal that invoked this signal handler.
Supports CERT C SIG34-C - Do not call signal() from within interruptible signal handlers
Supports CWE-364 - Signal Handler Race Condition
Supports CWE-479 - Signal Handler Use of a Non-reentrant Function

2764
info
exception signal handler symbol does not explicitly end the program
An exception signal handler did not appear to unconditionally end the program. (The end of the function body was reachable for the purposes of message 527 .) This could potentially lead to undeﬁned behavior.
Supports CERT C SIG35-C - Do not return from a computational exception signal handler

2765
info
reference to variable symbol which is neither atomic nor volatile sig_atomic_t within signal-handler-category symbol
A signal handler referenced a non-local variable that was not _Atomic, std::atomic<T>, nor volatile sig_atomic_t. This is likely to cause undeﬁned behavior.
Supports CERT C SIG31-C - Do not access shared objects in signal handlers
Supports CWE-364 - Signal Handler Race Condition
Supports CWE-662 - Improper Synchronization

2770
note
type of mutex 'name' is incomplete 'string' but its usage requires speciﬁc type
A mutex was locked recursively or was used with a shared-locking function but the mutex was not initialized in a way that PC-lint Plus could verify the recursive or shared property of the mutex. PC-lint Plus will assume that the mutex is a valid recursive or shared mutex based on its usage. Supplemental messages will provide the locations where the mutex is initialized and the locations where the mutex was locked or unlocked in shared mode or locked recursively.

This message is suppressed if inter-module thread analysis is disabled (see Inhibition of Thread Analysis ).
Supports MISRA C 2012 AMD4 Rule 22.14 - Thread synchronization objects shall be initialized before being accessed
Supports MISRA C:2023 Rule 22.14 - Thread synchronization objects shall be initialized before being accessed
Supports MISRA C:2025 Rule 22.14

2771
note
type of mutex 'name' is incomplete 'string'
A mutex was used but PC-lint Plus was unable to deduce the shared and/or recursive properties of the mutex. This will occur if the initialization(s) do not provide the information necessary to determine if the mutex is shared or recursive. Supplemental messages will provide the locations where the mutex is initialized.

2776
info
implicit conversion of string literal (context) to type is not const safe
A string literal was implicitly converted to a pointer to non-const character type via assignment (or implied assignment, see context). For example:

void my_function(char *); 
void foo(void) { 
   my_function("string");  // Info 2776 
}

Such an assignment opens the possibility for modiﬁcation of a string literal array, which is considered undeﬁned behavior by the C Standard.

See message 1776 for discarding the const qualiﬁer from a string literal in C++ code.
Supports CERT C STR05-C - Use pointers to const when referring to string literals
Supports CERT C STR30-C - Do not attempt to modify string literals
Supports MISRA C 2012 Rule 7.4 - A string literal shall not be assigned to an object unless the object’s type is "pointer to const-qualiﬁed char"
Supports MISRA C:2023 Rule 7.4 - A string literal shall not be assigned to an object unless the object’s type is "pointer to const-qualiﬁed char"
Supports MISRA C:2025 Rule 7.4

2840
info
for loop counter symbol used with equality operator but modiﬁed other than by ++ or –
A for loop counter was used as an operand to an equality operator inside of the condition of a for loop, but was modiﬁed other than by the ++ or -- operator in the iteration-expression of that loop. An implementation error may cause the loop to not terminate, and a relational operator should be considered for the loop condition instead.

for (int x = 0; x != 11; x += 3)  // info 2840

For the purpose of this message, a for loop counter is deﬁned as a variable that is an operand to a relational or equality operator in the for loop condition, and is modiﬁed in the iteration-expression.
Supports AUTOSAR17 Rule M6-5-2
Supports AUTOSAR19 Rule M6-5-2
Supports CERT C MSC21-C - Use robust loop termination conditions
Supports MISRA C++:2008 Rule 6-5-2 - If loop-counter is not modiﬁed by – or ++, then, within condition, the loop-counter shall only be used as an operand to <=, <, > or >=.

2865
info
string
A #pragma message directive was encountered. The text of this message is the string provided in the pragma.

2901
note
stack usage information: detail
When generating stack reporting data, if the fun ﬂag is set, this message will be issued once for each function in the stack report with detail containing the stack information for the function. See -stack for details.

2902
note
discarded instance of post-string operator
A post-increment or post-decrement operator was applied to a scalar in a context where the value will not be used (i.e. as an expression statement, as the left operand to the comma operator, or as the third clause of a for statement). A modern optimizing compiler is virtually guaranteed to elide the wasteful copy implied by such an operation when the value is not used but some may prefer to use pre-increment or pre-decrement operators instead for clarity and consistency. See also 1757 for potentially more serious cases involving user-deﬁned types.

2903
note
initializer list has a chained designator and at least one other ﬁeld without a designator
There was an initializer list in which there exists a chained designator and at least one ﬁeld that was not initialized using a designator. For example,

   struct Point2D { 
      int x; 
      int y; 
   }; 
 
   struct Point4D { 
      int w; 
      struct Point2D s; 
      int z; 
   }; 
 
   struct Point4D my_point = { 
          1, 
          .s.x = 2, 
          3, 
          4, 
   };

This message only takes into consideration one level of nested initializers at a time. It is not a violation when, taken as a whole, inner and outer nesting levels have mixed positional initializers or chained designators. Only when a single level of initializers has a mix.
Supports MISRA C 2012 AMD4 Rule 9.6 - An initializer using chained designators shall not contain intiializers without designators
Supports MISRA C:2023 Rule 9.6 - An initializer using chained designators shall not contain intiializers without designators
Supports MISRA C:2025 Rule 9.6

2904
note
chained designator conﬂicts with usage of positional braced initializer list for the same sub-object
A sub-object was initialized

1.: via braced initializer list in which at least one init expression was positional.
2.: At some point before or after this initializer list, a ﬁeld of the same sub-object was initialized via chained designator in the enclosing init list.

For example,

   struct Inner { 
      int x; 
      int y; 
      int z; 
   }; 
 
   struct Outer { 
      struct Inner i; 
   }; 
 
   struct Outer o = { 
      .i.z = 3, 
      .i = {1,2}, 
   };

will produce this message.
Supports MISRA C 2012 AMD4 Rule 9.6 - An initializer using chained designators shall not contain intiializers without designators
Supports MISRA C:2023 Rule 9.6 - An initializer using chained designators shall not contain intiializers without designators
Supports MISRA C:2025 Rule 9.6

2920
note
unlocking order mismatch
A set of mutexes was unlocked in an order inconsistent with the locking order. For example:

#include <mutex> 
 
std::mutex m1, m2; 
int my_data = 0; 
 
void foo(int i) { 
   m1.lock(); 
   m2.lock(); 
 
   ++my_data; 
 
   m1.unlock();  // 2920: unlocked before m2 
   m2.unlock(); 
}

While it is generally considered good practice to unlock mutexes in the reverse order in which they were locked, inconsistent unlocking order does not suﬀer the same potential issues as inconsistent locking order (which is diagnosed by message 2462 ).

2932
note
macro name used as header guard is followed by a #deﬁne of a diﬀerent macro 'name'
A macro with a name that is diﬀerent from the header guard macro was deﬁned immediately after the header guard. It is conventional practice to deﬁne the macro used in the header guard check but this is not always done for every ﬁle; this message can be used to identify those that do not follow this pattern. The more egregious violations (those that deﬁne a macro with a very similar name) are ﬂagged by message 2432 .

2960
note
integer constant expression with value integer provided as argument integer to function symbol
An integer constant expression was provided as an argument to a function parameter which was designated with the noliteral argument semantic indicating that the argument should not be a literal. While an integer constant expression does not necessarily consist of a single literal, it may be suspicious for many of the same reasons as the value is constant. For example, perhaps you do not want srand to be seeded with a constant expression to ensure it produces a diﬀerent sequence on each execution. This message can be enabled or suppressed for speciﬁc constant values.
Supports CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
Supports CWE-330 - Use of Insuﬃciently Random Values
Supports CWE-331 - Insuﬃcient Entropy
Supports CWE-337 - Predictable Seed in Pseudo-Random Number Generator (PRNG)
Supports MISRA C 2004 Rule 20.3 - The validity of values passed to library functions shall be checked.
Supports MISRA C 2012 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2023 Dir 4.11 - The validity of values passed to library functions shall be checked
Supports MISRA C:2025 Dir 4.11

22.5 Messages 3000-3999

3401
warning
parameter to move constructor symbol is an rvalue reference to const
There are relatively few valid reasons to declare a move constructor taking an rvalue reference to const but this construct could easily be formed by accident due to its similarity to a canonical copy constructor. This message will not be given if the move constructor is deleted, as this is occasionally useful.
Supports MISRA C++:2023 Rule 15.0.2 - User-provided copy and move member functions of a class should have appropriate signatures

3402
warning
lambda capture default captures 'this' by value
The this pointer was implicitly captured due to a member access inside a lambda. For clarity and to avoid an accidental use-after-free, some prefer to explicitly specify this in the capture list.

This message is emitted for lambdas where the default capture is by value. Access to a member with default capture by value does not capture the member by value but instead captures the this pointer. Use of the member within the lambda is still subject to the lifetime of the object pointed to by the this pointer.

This message is considered more severe than message 3702 for default capture by reference because the situation reported by that message is less likely to cause misinterpretation of object lifetime considerations, while the situation reported by message 3402 could easily lead to a use-after-free.

3403
warning
use of std::move on value of forwarding reference type type; was std::forward<string> intended?
A forwarding reference (sometimes referred to as a universal reference) was given as an argument to std::move. Either the formation of a forwarding reference instead of an rvalue reference or the use of std::move instead of std::forward was likely accidental. For example:

template<typename T> 
void f(T&& t) { 
   g(std::move(t)); // might unexpectedly move from the caller's lvalue 
}

Supports CWE-843 - Access of Resource Using Incompatible Type (‘Type Confusion’)

3405
warning
symbol is speciﬁed with C linkage but returns type type which is incompatible with C
A function was speciﬁed as having C language linkage but the function returns a type that is not compatible with C so what is the point in having C linkage?

3406
warning
incomplete return type type for function symbol speciﬁed with C linkage
A function that was speciﬁed as having C language linkage has an incomplete return type.

3407
warning
symbol should not return null unless declared with 'throw()' or 'noexcept'
The implementation for an operator new function has the possibility to return null but the function is not declared with ’throw()’ or ’noexcept’. Operator new functions should never return null except in these cases.
Supports AUTOSAR19 Rule A18-5-9

3408
warning
address of reference in comparison is never null in well-formed C++
The address of a reference was directly compared to null. This is suspicious because the address of a reference can never be null in well-formed code

void foo(int &i) { 
 int &ri = i; 
 if (&i == 0) return;  // 3408 
 if (&i != 0) return;  // 3408 
}

3409
warning
address of reference in boolean context is never null in well-formed C++
The address of a reference was used in a boolean context. This is suspicious because such an address can never be false. For example:

void foo(int &i) { 
 int &ri = i; 
 if (&i) return;   // 3409 
 if (&ri) return;  // 3409 
 if (!&i) return;  // 3409 
}

3410
warning
conversion function converting type to itself will never be used
A class contains a conversion function that converts to the type of the class itself. This is suspicious because such a conversion function will never be called. For example:

class X { 
  operator X(); 
};

will elicit this message.

3411
warning
conversion function converting type to its base class type will never be used
A class contains a conversion function that converts to the type of its base class. This is suspicious because such a conversion function will never be called. For example:

class X { }; 
class Y : public X { 
  operator X(); 
};

will elicit this message.

3412
warning
type has virtual functions but non-virtual destructor
A class contains at least one virtual function but has a non-private, not-virtual destructor. Classes that may be used as base classes should always have virtual destructors to ensure that instances of derived classes that are deleted through a pointer to the base class are properly destructed. The declaration of a virtual function implies that this class is meant to be used as a base class and as such it should provide a virtual destructor.

3413
warning
delete/destructor called on non-ﬁnal type that has virtual functions but non-virtual destructor
This message is similar to 3412 but while the former warns about the potential problem that could arise from having a non-virtual destructor, this message warns when delete is applied to such an object.

3414
warning
delete/destructor called on type that is abstract but has non-virtual destructor
This message is similar to 3413 but is reported for abstract types.

3415
warning
pointer initialized to temporary array
A pointer is being initialized with a temporary array, which will be destroyed at the end of the containing expression making it impossible to safely dereference the pointer before assigning a new value to it. For example:

struct S { int array[10]; }; 
 
void f() { 
   int *pi = S().array;  // warning 3415, array pointed to by pi 
                      // will cease to exist after initialization. 
}

3416
warning
'this' pointer used in boolean context is never null
The this pointer was used in a boolean context such as:

if (this) ...

Was this a mistake? The this pointer is never null in well-formed C++ so such a test is suspect.

3417
warning
'this' pointer used in comparison is never null
The this pointer is explicitly tested for null such as

if (this == 0)

Was this a mistake? The this pointer is never null in well-formed C++ so such a test is suspect.

3418
warning
'reinterpret_cast' string class symbol string its string symbol behaves diﬀerently than 'static_cast'
A reinterpret_cast was used to cast between a class type and a base class type in an unsafe way; static_cast should probably be used instead.
Supports MISRA C++:2023 Rule 8.2.1 - A virtual base class shall only be cast to a derived class by means of dynamic_cast

3419
warning
in-class initializer for static data member symbol of type type is a GNU extension
An in-class initializer for a static data member of ﬂoating point type was encountered. This is a non-portable extension.

3420
warning
extraneous template parameter list in template specialization
An extraneous template parameter list was provided in the declaration of a template specialization. For example:

template <typename T> 
T foo(T); 
 
template<>      // warning 3420 
template<> 
int foo(int);

3421
warning
string template partial specialization contains string that cannot be deduced so the specialization will never be used
In the partial specialization of a class or variable template, the presence of one or more template parameters that cannot be deduced means that the specialization will never be used. Was this a mistake?

3423
warning
case value/enumerator value/non-type template argument/array size/constexpr if cannot be narrowed from type to type
A case value, enumerator value, non-type template argument, or array size was provided that cannot be narrowed to the required type. For example:

void foo(unsigned u) { 
   switch(u) { 
   case -1:       // warning 3423, cannot narrow -1 to unsigned 
      break; 
      ... 
      } 
} 
 
template <unsigned char I> 
struct S { unsigned char value = I; }; 
S<300> s;         // warning 3423, cannot narrow 300 to unsigned char

3424
warning
constexpr/consteval function/constructor never produces a constant expression
A function marked as constexpr or consteval must contain at least one code path that produces a constant expression to be used in a context where a constant expression is required. The speciﬁed function was marked as constexpr or consteval but does not ever produce a constant expression so the use of constexpr/consteval is suspect.

3425
warning
type type cannot be narrowed to type in initializer list
Inside an initializer list, a prohibited implicit narrowing conversion would be required to perform the initialization. The prohibited implicit conversion is one that is never allowed in list initialization. For example:

int i = { 3.0 };

will elicit this message because conversion from a ﬂoating point type to a integral type is required to perform the initialization but is not an allowed implicit conversion within an initializer list. The issue can be corrected by correcting the type used in the initializer, casting the type, or not using list initialization.

3426
warning
non-constant-expression cannot be narrowed from type type to type in initializer list
Inside an initializer list, a prohibited implicit narrowing conversion would be required to perform the initialization. The implicit conversion is of a type that is allowed for constant expressions but not for the provided expression. For example:

extern int i; 
float f = { i; };

will elicit this message while:

float f = { 3 };

will not. The issue can be corrected by correcting the type used in the initializer, casting the type, or not using list initialization.

3427
warning
constant expression evaluates to string which cannot be narrowed to type type
Inside an initializer list there is an implicit conversion of a constant expression to a type where the value cannot be represented exactly, which is prohibited. For example:

unsigned char c = { 1234 };

will elicit this message, assuming 8-bit chars. The message can be avoided by correcting the value, using a cast, or by not employing list initialization.

3428
warning
out-of-line declaration of a member must be a deﬁnition
A class member that is declared out-of-line (outside of the class declaration) must have a deﬁnition. For example:

class A { 
   void foo(); 
} 
 
void A::foo();

The second declaration of A::foo must contain a deﬁnition.

3429
warning
parenthesized initialization of a member array is a GNU extension
In C++11, an array member can be initialized in a member initialization list using extended initializer syntax, e.g.:

class A { 
   A() : array { 0 } { }; 
   int array[10]; 
}

A deprecated GNU extension allowed an array member to be initialized using the syntax for initializing class types:

A() : array({ 0 });

This parenthesis around the initializer here are not Standard.

3430
warning
taking the address of a temporary object of type type
An attempt was made to take the address of a temporary object. For example:

struct X { ... }; 
 
void foo() { 
   &X();      // warning 3430 
}

3431
warning
in-class initializer for static data member of type type requires 'constexpr' speciﬁer
A const static data member of integral type may be initialized in its in-class declaration with a constant expression. For non-integral types, the member must be declared with constexpr, e.g.:

struct A { 
   const static int i = 3; 
   constexpr static float f = 3.0; 
};

This message is issued for non-integral static data members with an in-class initializer of a type for which constexpr is expected but not provided.

3432
warning
invalid suﬃx on literal, C++ 11 requires a space between literal and identiﬁer
A literal appeared adjacent to an identiﬁer but there was no space separating the two and the identiﬁer was not a valid suﬃx for the literal.

3433
warning
constructor|destructor function-try-block handler references non-static member string
This warning is issued when a constructor or destructor function-try-block handler references a non-static member of the class. Referring to a non-static member of a class (or its bases) within the handler of a function-try-block of its constructor or destructor results in undeﬁned behavior.

For example:

class A { 
   int x; 
 
public: 
   A() try { 
   } catch (...) { 
      x++;  // warning 3433 
   } 
};

Supports AUTOSAR17 Rule M15-3-3
Supports AUTOSAR19 Rule M15-3-3
Supports MISRA C++:2008 Rule 15-3-3 - Handlers of a function-try-block implementation of a class constructor or destructor shall not reference non-static members from this class or its bases.
Supports MISRA C++:2023 Rule 18.3.3 - Handlers for a function-try-block of a constructor or destructor shall not refer to non-static members from their class or its bases

3435
warning
non-throwing allocation function symbol throws a std::bad_alloc exception
A std::bad_alloc exception was found being thrown in an operator new implementation that is declared as not throwing. Replacement versions of operator new that are non-throwing are required to return a null pointer when not returning suitably aligned storage. This message will always be emitted when a std::bad_alloc exception is thrown if the fnn (new can return null) ﬂag is active. If an operator new function should throw a std::bad_alloc exception but does not, then message 3436 will be reported. See also message 3407 .
Supports AUTOSAR19 Rule A18-5-9

3436
warning
allocation function symbol does not throw a std::bad_alloc exception
The implementation for an operator new function does not throw a std::bad_alloc exception. Replacement versions of operator new are required to throw a std::bad_alloc exception when not returning suitably aligned storage, unless the function is speciﬁed as not throwing. This message will not be emitted if the fnn (new can return null) ﬂag is active. If an operator new function is declared as not throwing but still throws a std::bad_alloc exception, then message 3435 will be reported. See also message 3407 .
Supports AUTOSAR19 Rule A18-5-9

3437
warning
pointer argument symbol to placement new symbol is not suitably aligned
A call to placement new occurred in which the pointer passed as a placement argument points to an object whose alignment does not match that of the allocated type. For example:

long l = 0; 
int* ip = ::new(&l) int;  // warning 3437

The pointer argument to new above has the default alignment of a long, while the allocated type has the default alignment of an int.
Supports AUTOSAR19 Rule A18-5-10

3438
warning
pointer argument symbol to placement new symbol does not provide suﬃcient storage
A call to placement new occurred in which the pointer passed as a placement argument points to an object of a size that does not provide suﬃcient storage for the allocated type. For example:

short s = 0; 
int* ip = ::new(&s) int;  // warning 3438

Here, assuming the size of an int is 4 bytes and the size of a short is 2 bytes, the pointer argument provides less storage than is required by the allocated type.
Supports AUTOSAR19 Rule A18-5-10

3450
warning
subtracting value of member symbol from the address referred to by the 'this' pointer; use of -> to access the member may have been intended
The integral or pointer value of a member of this, accessed implicitly through the current object, was subtracted from the this pointer. This is almost certainly a mistake where the > in -> was forgotten.
For example:

1struct X { 
2   bool value; 
3   bool getValue() const { 
4      return this-value; // intended to be this->value 
5   } 
6};

If for some reason explicitly applying a negative oﬀset to the this pointer based on a member value is actually desired then the member name can be enclosed in parentheses to avoid confusion.

3513
warning
class symbol declares string but does not declare string
This message is emitted to enforce the Rule of Three which states, if a class requires a user-deﬁned destructor, a user-deﬁned copy constructor, or a user-deﬁned copy assignment operator, it almost certainly requires all three.

class C {  // warn 3513 
public: 
   C() { p = new int[10]; } 
   ~C() { delete p; } 
private: 
   int* p; 
};

The rule recommends to implement all three of these functions, or none of them. This message is only issued in language modes prior to C++11, because those language standards directed the compiler to generate missing implicitly deﬁned destructors, copy constructors, and copy assignment operators, even if only one of these is deﬁned. The implicitly deﬁned functions will not correctly deal with memory or resource management, which warrants a user deﬁned function being present.

The string arguments to this function concatenate the following strings, using a comma, based on whether they are declared or missing. The list of strings will always appear in the following order.

a copy assignment operator
a copy constructor
a destructor

See message 3713 and 3913 for when running with language modes C++11 or later.

3537
warning
const member function symbol exposes reference member symbol as non-const reference
A const function is behaving suspiciously. It is returning a non-const reference non-static data member. For example,

class X { 
   int& r; 
public: 
   int& f() const { return r; }  // warning 3537 
};

Since f is supposedly const and since r is presumptively referencing data that is logically part of class X, there is the possibilty for the referenced data to be accessed from outside of the class. Either return a const reference or remove the const modiﬁer to the function.

See message 1537 for returning a non-const pointer to a data member in a const member function.
Supports AUTOSAR17 Rule M9-3-1
Supports AUTOSAR19 Rule M9-3-1
Supports MISRA C++:2008 Rule 9-3-1 - const member functions shall not return non-const pointers or references to class-data.

3548
warning
function symbol marked as potentially-throwing/non-throwing which conﬂicts with another declaration
The same function has been declared with an incompatible exception speciﬁer. These checks will only be performed across modules, and not in the same module.

a.cpp

void fn() noexcept;  // warn 3548

b.cpp

void fn();  // warn 3548

Only the possibilty to throw will be compared. The types of dynamic exception speciﬁcations will not be considered when comparing functions across modules. See message 1548 to check these types intramodule.
Supports AUTOSAR17 Rule A15-4-3
Supports AUTOSAR19 Rule A15-4-3
Supports MISRA C++:2008 Rule 15-4-1 - If a function is declared with an exception-speciﬁcation, then all declarations of the same function (in other translation units) shall be declared with the same set of type-ids.

3701
info
use of symbol implicitly invokes converting constructor symbol; symbol could be used [without braces]
A push, push_back, or insert function is called in a situation where emplace_back or emplace could be used instead.

3702
info
lambda capture default captures 'this' by value
The this pointer was implicitly captured due to a member access inside a lambda. For clarity, some prefer to explicitly specify this in the capture list.

This message is emitted for lambdas where the default capture is by reference. Access to a member with default capture by reference does not directly capture the member by reference but instead captures the this pointer.

This message is considered less severe than message 3402 for default capture by value because the situation reported by that message could easily lead to a use-after-free, while the situation reported by message 3702 is less likely to cause misinterpretation of object lifetime considerations.

3703
info
ellipsis at this point creates a C-style varargs function
An ellipsis was encountered, which was probably intended to declare a function parameter pack but instead declares a variable argument function. For example:

template <typename... T> 
void foo() { 
   bar([] { 
      void g(T t...);    // warning 3703, probably meant g(T... t); 
   }...); 
}

3704
info
empty parentheses here declare a function, not a variable
A set of empty parenthesis were added to what would otherwise be interpreted as a variable declaration but instead results in the declaration of a function. For example:

struct S { 
   S(int a = 0) : _a(a) { } 
   int _a; 
}; 
 
void foo() { 
   S s1(1);    // OK, declares and initializes variable s1 
   S s2();     // warning 3704, declares a function s2 
}

s2 is interpreted as a function that returns type S and takes not arguments, not a zero-initialized variable as presumably intended.

There are multiple ways to force interpretation of a variable, e.g.:

S s3(0);   // OK 
S s4 = S(); // OK, initialize via temporary 
S s5{};    // OK, C++11 uniform initialization

See also message 3705 .
Supports MISRA C++:2023 Rule 6.0.1 - Block scope declarations shall not be visually ambiguous

3705
info
parenthetic disambiguation results in function declaration
A syntactic construct was encountered that could be interpreted as either a variable declaration or a function declaration (sometimes referred to as the "most vexing parse"). The C++ disambiguation rules require that it be interpreted as a function declaration, which may not be what the programmer intended. For example:

struct X { }; 
struct Y { 
   Y(const X&); 
}; 
 
void foo() { 
   Y y(X());  // warning 3705 
}

Here y is interpreted as a function that returns an object of type Y and takes a single parameter that is a pointer to a function taking no arguments and returning type X. In particular, it is not interpreted as a declaration of an object of type Y initialized with a temporary of type X as was almost certainly intended.

There are several ways to force interpretation of a variable declaration. In C++11 and later the simplest way is to employ uniform initialization syntax, for example any of the following would work:

Y y1(X{});   // OK, variable declaration 
Y y2{X()};   // OK, variable declaration 
Y y3{X{}};   // OK, variable declaration

Prior to C++11, an extra pair of parenthesis can be used to force the desired interpretation, e.g.:

Y y4((X()));  // OK, variable declaration

The same issue can appear with casts, for example:

void foo(double d) { 
   int i( int(d) );   // warning 3705 
}

In this case, i is not a variable initialized with the truncated value of d but rather a function returning int and taking int. In addition to the methods mentioned above to force a variable declaration, the functional cast can be converted to a C-style cast or a named cast, e.g.:

int i1( (int) d );            // OK, variable declaration 
int i2( static_cast<int>(d) );  // OK, variable declaration

Supports MISRA C++:2023 Rule 6.0.1 - Block scope declarations shall not be visually ambiguous

3706
info
abstract class symbol marked 'ﬁnal/sealed'
An abstract class (one that contains at least one pure virtual speciﬁer) was marked as final or sealed preventing the class from being used as a base class. Since abstract classes cannot be instantiated, what would be the purpose of having abstract class that cannot be inherited from?

3707
info
unknown linkage language 'string'
C++ deﬁnes the language linkage speciﬁers "C" and "C++". Other speciﬁers may be supported by compilers as an extension with implementation-deﬁned semantics. This message is issued when a language linkage speciﬁer other than "C" or "C++" is encountered. For example:

extern "C" int a;      // Okay 
extern "C++" int b;    // Okay 
extern "ADA" int c;    // Info 3707

3708
info
global/local variable symbol has static/thread storage duration but is not constant-initialized
A variable with static or thread storage duration, such as a global variable, function scope static variable, or static class data member has been found to have an initializer that is not a constant-initializer. A static class data member is considered a "global" variable for the purposes of the ﬁrst message parameter.

Not using a constant-initializer can lead to an indeterminate initialization order of these variables. The following example across three modules demonstrates indeterminate ordering:

unorderedA.cpp

extern int global; 
class A { 
public: 
   A() { 
      global = 1; 
   } 
}; 
static A instance; // info 3708

unorderedB.cpp

extern int global; 
class B { 
public: 
   B() { 
      global = 2; 
   } 
}; 
static B instance; // info 3708

unordered.cpp

int global = 0; 
 
int main() { 
   return global; 
}

The return code of the generated executable is unspeciﬁed and may diﬀer between compilers or may depend on the order in which modules are linked into the executable.

This message is not issued in C modules as objects with static or thread storage duration are required to be initialized with either a constant expression or string literal.

Message 1544 is available which diagnoses when the value of a variable is indeterminate due to run time initialization. Cases detected by message 1544 will be a subset of cases detected by this message.

Message 9508 is available to diagnose implicit zero-initialization of static or thread storage duration variables.
Supports AUTOSAR19 Rule A3-3-2

3709
info
global detail operator new/delete deﬁned without corresponding detail operator delete/new
This message is issued whenever a global replacement operator new or delete has been deﬁned for a project, but the project does not deﬁne both operator new and delete. The message is issued separately for array and non-array versions of the operators, as well as alignment requirement and non-alignment requirement variants of operators.

Note that user-deﬁned placement allocation and deallocation functions do not count as global replaceable functions, and this diagnostic will not consider them when determining matching functions.

Similarly, this diagnostic will not consider std::no_throw_t tagged operator delete functions. These are only called when a constructor throws an exception and should not be relied upon to always deallocate memory from a corresponding operator new function.

Assuming there is no global operator new deﬁned in this project, the message would be issued for:

void operator delete(void* ptr) noexcept { free(ptr); }  // info 3709 
void operator delete[](void* ptr) noexcept { free(ptr); }  // info 3709

The message 3710 implements the same check, but is limited to class scope.
Supports AUTOSAR19 Rule A18-5-11

3710
info
class type declares detail operator new/delete without corresponding detail operator delete/new
This message is issued when a class declares either a custom operator new or delete, but not both. The message is issued separately for array and non-array versions of the operators. For example:

class A { 
public: 
   void operator delete(void* ptr) { free(ptr); }  // info 3710 
   void operator delete[](void* ptr) { free(ptr); }  // info 3710 
};

will trigger the message.

The message 3709 implements the same check at global scope.
Supports AUTOSAR19 Rule A18-5-11

3711
info
move called with argument of const-qualiﬁed type type
The moved argument of a function with move function semantics has a const-qualiﬁed type, and hence will not be moved.

const A obj; 
A other = std::move(obj); // info 3711

Custom move functions can be added with the option -sem using the move semantic. Note that to be considered a move function for the purposes of this message, the function must return an rvalue reference.

See message 3911 for an rvalue argument passed to a move function.
Supports AUTOSAR17 Rule A18-9-3
Supports AUTOSAR19 Rule A18-9-3
Supports MISRA C++:2023 Rule 28.6.1 - The argument to std::move shall be a non-const lvalue

3712
info
potentially throwing constructor symbol would be called during program/thread initialization
A constructor that may potentially throw an exception is used to initialize a ﬁle scope static or thread storage duration variable. Constructors with the exception speciﬁcation noexcept(false) will always be considered to potentially throw.

class A { 
public: 
   A() noexcept(false) {} 
}; 
 
A obj;  // info 3712

If a constructor throws an exception during initialization of static or thread storage duration objects, std::terminate may be called to abruptly exit the program. Local variables with static or thread storage duration can safely handle exceptions thrown during initialization since they are initialized upon ﬁrst use so this message will not be emitted for them.

See message 3912 for potentially throwing constructors invoked inside of a constexpr or consteval function.
Supports AUTOSAR17 Rule A15-2-1
Supports AUTOSAR19 Rule A15-2-1

3713
info
class symbol declares string but does not declare string
This message is emitted to enforce the Rule of Five which is an extension of the Rule of Three. See message 3513 for the deﬁnition of the Rule of Three. The Rule of Five also includes the move assignment operator and move constructor of a class.

class C {  // info 3713 
public: 
   C() { p = new int[10]; } 
   ~C() { delete p; } 
private: 
   int* p; 
};

The rule recommends to implement, default, or delete all ﬁve of these functions, or to not declare any of them which allows the compiler to implicitly deﬁne them all.

This message is only issued in language modes C++11 or later, because those language standards do not allow the compiler to implicitly generate any of these functions when at least one of them is deﬁned. Therefore, omitting some of the ﬁve members will not lead to unexpected behavior.

Message 3913 is issued instead of this message when only the move assignment operator or move constructor is missing, since that is a less severe violation of the Rule of Five, leaving only a performance optimization opportunity on the table.

The string arguments to this function concatenate the following strings, using a comma, based on whether they are declared or missing. The list of strings will always appear in the following order.

a copy assignment operator
a copy constructor
a destructor
a move assignment operator
a move constructor

See message 3513 for when running with language modes earlier than C++11. See message 3913 for when only the move assignment operator or move constructor is missing.
Supports AUTOSAR17 Rule A12-0-1
Supports AUTOSAR19 Rule A12-0-1

3714
info
suﬃx 'string' of user-deﬁned literal operator symbol does not start with a single underscore
User deﬁned literal suﬃx identiﬁers that do not start with a single underscore are reserved for future standardization. This message will not be issued for any declarations in the std namespace.

float operator ""E(const char*);  // info 3714

To diagnose non-letter characters being used after the singe underscore, see message 9514 (user deﬁned literal suﬃx contains non-letter after underscore).
Supports AUTOSAR17 Rule A13-1-2
Supports AUTOSAR19 Rule A13-1-2

3715
info
forward parameter symbol of function symbol is used outside of forwarding
A non-const templated rvalue reference function parameter was used in an operation. Since these function parameters can bind to an object of any value category, using this parameter may be dangerous depending on the value category and operation. No other operations should be performed on the parameter.

template<typename T> 
auto makeMyClass1(T&& a) { return MyClass(std::forward(a)); }  // Okay 
 
template<typename T> 
auto makeMyClass2(T&& a) { 
   a++;  // info 3715 
   return MyClass(std::forward(a)); 
}

Parameters of a generic lambda declared as auto&& are also considered forwarding parameters.
See message 3716 for forward parameters that are not forwarded.
Supports AUTOSAR19 Rule A8-4-6

3716
info
forward parameter symbol of function symbol not forwarded
A non-const templated rvalue reference function parameter was not forwarded in the body of the function. Since these function parameters can bind to an object of any value category, using this parameter may be dangerous depending on the value category and operation. No other operations should be performed on the parameter.

template<typename T> 
auto makeMyClass1(T&& a) { return MyClass(std::forward(a)); }  // Okay 
 
template<typename T> 
auto makeMyClass2(T&& a) { return MyClass(a); }  // info 3716

Parameters of a generic lambda declared as auto&& are also considered forwarding parameters. Function parameters of functions that are deleted or defaulted will not receive this message.
See message 3715 for forward parameters that are used in an operation outside of forwarding.

Custom forward functions can be added with the option -sem using the forward semantic.
Supports AUTOSAR19 Rule A8-4-6

3717
info
declaration will not be found through a prior using-declaration
A function overload is declared which is missed by a previous using-declaration that introduces the function name. Using-declarations only introduce prior declarations. Subsequent declarations will not be found through the using-declaration. For example:

namespace N { 
   void f(int); 
} 
using N::f; 
namespace N { 
   void f(float);  // Info 3717, overload not introduced by the using-declaration 
} 
 
int main() { 
   f(0.f);  // N::f(int) will be called 
}

Supports AUTOSAR17 Rule M7-3-5
Supports AUTOSAR19 Rule A7-3-1
Supports MISRA C++:2008 Rule 7-3-5 - Multiple declarations for an identiﬁer in the same namespace shall not straddle a using-declaration for that identiﬁer.

3780
info
returning reference of a const/rvalue reference parameter symbol
A reference to a const reference or a rvalue reference parameter is being returned from a function. The danger of this is that the reference may designate a temporary variable that will not persist long after the call.

const int& f(const int& n) 
   { return n; }  // info 3780 
int g(); 
const int& p = f( g() );

Here, p binds to a temporary value whose duration is not guaranteed. If the reference is not const or an rvalue reference then message 3980 will be emitted instead.

Message 1780 deals with the memory address of const reference parameters being returned.
Supports AUTOSAR17 Rule A7-5-1
Supports AUTOSAR19 Rule A7-5-1
Supports MISRA C++:2008 Rule 7-5-3 - A function shall not return a reference or a pointer to a parameter that is passed by reference or const reference.

3901
note
reference to data member/member function symbol of symbol does not use an explicit 'this->'
A non-static data member or function was referenced inside of the containing class with an implicit this object instead of using this->member to access the member. For example:

struct A { 
   int value; 
   int getValue() { return this->value; }  // OK, explicit this-> 
   void setValue(int v) { value = v; }    // note 3901 
};

Some authors suggest always using this-> to access members to prevent the potential for confusion when local objects or functions with the same name as a member exist in the same scope. See also message 578 , which will be issued if a local symbol is declared that hides a member.

3902
note
thrown object of type type is not a class derived from std::exception
This message is issued where a throw-expression initializes an exception object that is not derived from std::exception. The point is to have a type that can be caught by

catch(std::exception & p)

instead of

catch(...)

This way, in a situation where it’s necessary to catch everything, information about the kind of error can at least be logged or translated.
Supports AUTOSAR17 Rule A15-1-1
Supports AUTOSAR19 Rule A15-1-1

3903
note
lambda implicitly returning [undeduced] type [written as 'auto'/'decltype(auto)'] does not explicitly specify return type
A lambda expression did not explicitly specify a return type. A return type of auto or decltype(auto) is not considered to be explicitly speciﬁed. This message is not emitted for a lambda expression returning void.
Supports AUTOSAR17 Rule A5-1-6
Supports AUTOSAR19 Rule A5-1-6

3904
note
globally deﬁned unsized/sized string operator delete does not have complimentary sized/unsized deﬁnition
This message is issued whenever a global replacement operator delete has been deﬁned for a project, but the project does not deﬁne a version of this function both with and without a size parameter.

This message is only issued if sized deallocations (C++14) are possible, and if the given function has the possibility to be deﬁned both with and without a size parameter. String will either be empty or one of "array", "aligned", or "aligned array".

Assuming this is the only global operator delete deﬁned in a project, this message would be issued for:

void operator delete(void* ptr) noexcept { free(ptr); } // note 3904

Note that the fzd ﬂag will need to be enabled to indicate that sized deallocations are possible, which is a prerequisite for emitting this note. If the faa ﬂag is enabled, this note is eligible to be issued for operator delete deﬁnitions that use alignment parameters.
Supports AUTOSAR17 Rule A18-5-4
Supports AUTOSAR19 Rule A18-5-4
Supports MISRA C++:2023 Rule 21.6.4 - If a project deﬁnes either a sized or unsized version of a global operator delete, then both shall be deﬁned

3905
note
symbol has been previously forwarded but is used
A variable that was previously the forwarded argument of a function with forward semantics has been subsequently used.

template <typename T> 
void foo(T&& var) 
{ 
   bar(std::forward<T>(var)); 
   ++var; // note 3905 
};

Custom forwarding functions can be added with the option -sem using the forward semantic.
Supports AUTOSAR17 Rule A18-9-4
Supports AUTOSAR19 Rule A18-9-4

3907
note
multiple function calls in for-range-initializer
A C++11 range-based for loop was found with a for-range-initializer that contained more than one function call.

for (auto i : make().range());  // note 3907

The for loop will apply lifetime extension to the outermost temporary object for the for-range-initializer, but it will not extend the lifetime of any intermediate temporary objects. Calling multiple functions in the initializer may or may not create multiple temporary objects whose lifetimes will not be extended. In C++23 and later all temporaries created in a for-range-initializer will have their lifetimes extended, and therefore this message won’t be issued.

See message 1901 to see where all temporaries are created.
Supports MISRA C++:2023 Rule 9.5.2 - A for-range-initializer shall contain at most one function call

3910
note
non-const rvalue reference parameter symbol not moved from
A non-template, non-const rvalue reference function parameter was not moved in the body of the function. Function parameters of functions that are deleted or defaulted will not receive this message. Function parameters without identiﬁers will not receive this message.

void consumeParameter(int&& a) {  // note 3910 
   b = a; 
}

These function parameters are explicitly marked as rvalue references to have the ability to be moved from. If the parameter will not be moved from, a lvalue reference or a pass-by-copy parameter may be more appropriate.

Custom move functions can be added with the option -sem using the move semantic.

Note that to be considered a move function, the function must return an rvalue reference.
Supports AUTOSAR19 Rule A8-4-5

3911
note
move called with prvalue/xvalue argument of type type
The moved argument of a function with move function semantics is an rvalue. Using a move function on an rvalue is redundant and unnecessary. This may be an indication that std::forward may be more appropriate, or that the move function can be removed.

int var = std::move(1); // note 3911

See message 3711 for a const argument passed to a move function.
Supports MISRA C++:2023 Rule 28.6.1 - The argument to std::move shall be a non-const lvalue

3912
note
potentially throwing constructor symbol would be called in constexpr/consteval function symbol
A constructor that may potentially throw an exception is used in the context of a constexpr or consteval function. Constructors with the exception speciﬁcation noexcept(false) will always be considered to potentially throw.

class A { 
public: 
   constexpr A() noexcept(false) {} 
}; 
 
constexpr void fn(void) { 
   A obj;  // info 3912 
}

If a constructor throws an exception during initialization of a static or thread storage duration variable that calls this function, std::terminate may be called to abruptly exit the program.

See message 3712 for potentially throwing constructors invoked directly during the initialization of a static or thread storage duration variable.
Supports AUTOSAR17 Rule A15-2-1
Supports AUTOSAR19 Rule A15-2-1

3913
note
class symbol declares string but does not declare string
This message is emitted to enforce the Rule of Five which is an extension of the Rule of Three. See message 3513 for the deﬁnition of the Rule of Three. The Rule of Five also includes the move assignment operator and move constructor of a class.

class C {  // note 3913 
public: 
   C() { p = new char[10]; p[0] = '\0'; } 
   ~C() { delete p; } 
   C(const C& c) { p = new char[10]; strcpy(p, c.p); } 
   C& operator=(C c) { swap(p, c.p); return *this; } 
   char* p; 
};

The rule recommends to implement, default, or delete all ﬁve of these functions, or to not declare any of them which allows the compiler to implicitly deﬁne them all.

This message is emitted speciﬁcally when only the move assignment operator or move constructor is missing. Message 3713 is issued instead of this message when one of the ﬁve members other than a move assignment operator or move constructor is missing, since that is a more severe violation of the Rule of Five. This message is only issued in language modes C++11 or later since that is when move semantics were added.

See message 3713 for a description of the string arguments to this message.

See message 3513 for when running with language modes earlier than C++11. See message 3713 for when a member other than just the move assignment operator or move constructor is missing.
Supports AUTOSAR17 Rule A12-0-1
Supports AUTOSAR19 Rule A12-0-1

3915
note
value of non-const lvalue-reference parameter symbol of function symbol is unused
The passed in value of a non-const lvalue-reference parameter is unused in the body of the function. Some coding guidelines suggest that such parameters only be used when you need to both read and write a value. If the value is reassigned before it’s used, then it is considered an out-only parameter. For example:

void add(int a, int b, int& result) {  // Note 3915 
   result = a + b; 
}

In this case, the output should be speciﬁed by the return type, with multiple outputs returned as a struct, tuple, or other multi-member type. If there is a valid reason to not use the return type, such as for objects which are expensive to move, then this message may be suppressed. For the purpose of this message, a call to a member function with a non-void return value is considered to be using the object. For detecting when a non-const reference parameter is unmodiﬁed, see message 1764 .
Supports AUTOSAR19 Rule A8-4-4
Supports AUTOSAR19 Rule A8-4-8

3980
note
returning reference of a non-const reference parameter symbol
A reference to a non-const reference parameter is being returned from a function.

int& f(int& n) 
   { return n; }  // note 3980 
int g = 0; 
int& p = f(g);

Since the parameter is non-const it will not bind to an rvalue, and it is not considered as dangerous as with a reference to a const or a rvalue reference. (See 1780 , and 3780 for those cases).
Supports MISRA C++:2008 Rule 7-5-3 - A function shall not return a reference or a pointer to a parameter that is passed by reference or const reference.

22.6 Messages 4000-6999

Messages in the 4xxx, 5xxx, and 6xxx ranges are used by PC-lint Plus to report clang compiler errors. Because these messages are generally self-explanatory syntax errors, detailed descriptions of the individual messages are not included in this manual.

22.7 Messages 8000-8999

8000
info
string
Messages in the 8xxx range are reserved for user-deﬁned diagnostics, see +message for more information.

22.8 Messages 9000-9999

9001
note
octal constant 'string' 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.
Supports AUTOSAR17 Rule M2-13-2
Supports AUTOSAR19 Rule M2-13-2
Supports CERT C DCL18-C - Do not begin integer constants with 0 when specifying a decimal value
Supports MISRA C 2004 Rule 7.1 - Octal constants (other than zero) and octal escape sequences shall not be used.
Supports MISRA C 2012 Rule 7.1 - Octal constants shall not be used
Supports MISRA C:2023 Rule 7.1 - Octal constants shall not be used
Supports MISRA C:2025 Rule 7.1
Supports MISRA C++:2008 Rule 2-13-2 - Octal constants (other than zero) and octal escape sequences (other than "\0") shall not be used.
Supports MISRA C++:2023 Rule 5.13.3 - Octal constants shall not be used

9003
note
could deﬁne global variable symbol within function string
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. This message is suppressed for unit checkout (-unit_check option).
Supports AUTOSAR17 Rule M3-4-1
Supports AUTOSAR19 Rule M3-4-1
Supports CERT C DCL19-C - Minimize the scope of variables and functions
Supports MISRA C 2004 Rule 8.7 - Objects shall be deﬁned at block scope if they are only accessed from within a single function.
Supports MISRA C 2012 Rule 8.9 - An object should be declared at block scope if its identiﬁer only appears in a single function
Supports MISRA C:2023 Rule 8.9 - An object should be declared at block scope if its identiﬁer only appears in a single function
Supports MISRA C:2025 Rule 8.9
Supports MISRA C++:2008 Rule 3-4-1 - An identiﬁer declared to be an object or type shall be deﬁned in a block that minimizes its visibility.

9004
note
object/function symbol previously declared
The named symbol was declared in multiple locations, not counting the point of deﬁnition for that symbol. Declaring a symbol in one location and in one ﬁle helps to ensure consistency between declaration and deﬁnition as well as avoiding the risk of conﬂicting deﬁnitions across modules.
Supports AUTOSAR17 Rule M3-2-3
Supports AUTOSAR19 Rule M3-2-3
Supports MISRA C 2004 Rule 8.8 - An external object or function shall be declared in one and only one ﬁle.
Supports MISRA C 2012 Rule 8.5 - An external object or function shall be declared once in one and only one ﬁle
Supports MISRA C:2023 Rule 8.5 - An external object or function shall be declared once in one and only one ﬁle
Supports MISRA C:2025 Rule 8.5
Supports MISRA C++:2008 Rule 3-2-3 - A type, object or function that is used in multiple translation units shall be declared in one and only one ﬁle.

9005
note
cast drops detail qualiﬁer(s)
A cast attempted to remove the qualiﬁers from an object to which a pointer points or a reference refers. Doing so can result in undesired or unexpected modiﬁcation of the object in question and may result in an exception being thrown.
Supports AUTOSAR17 Rule A5-2-3
Supports AUTOSAR19 Rule A5-2-3
Supports CERT C EXP05-C - Do not cast away a const qualiﬁcation
Supports CWE-704 - Incorrect Type Conversion or Cast
Supports MISRA C 2004 Rule 11.5 - A cast shall not be performed that removes any const or volatile qualiﬁcation from the type addressed by a pointer.
Supports MISRA C 2012 Rule 11.8 - A cast shall not remove any const or volatile qualiﬁcation from the type pointed to by a pointer
Supports MISRA C:2023 Rule 11.8 - A cast shall not remove any const or volatile qualiﬁcation from the type pointed to by a pointer
Supports MISRA C:2025 Rule 11.8
Supports MISRA C++:2008 Rule 5-2-5 - A cast shall not remove any const or volatile qualiﬁcation from the type of a pointer or reference.
Supports MISRA C++:2023 Rule 8.2.3 - A cast shall not remove any const or volatile qualiﬁcation from the type accessed via a pointer or by reference

9006
note
'sizeof' used on expression with side eﬀect
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-eﬀects not taking place. This message is not given if the operand is an lvalue of volatile qualiﬁed type and is not a variably-lengthed array.
Supports AUTOSAR17 Rule M5-3-4
Supports AUTOSAR19 Rule M5-3-4
Supports CERT C EXP44-C - Do not rely on side eﬀects in operands to sizeof, _Alignof, or _Generic
Supports MISRA C 2004 Rule 12.3 - The sizeof operator shall not be used on expressions that contain side eﬀects.
Supports MISRA C 2012 Rule 13.6 - The operand of the sizeof operator shall not contain any expression which has potential side eﬀects
Supports MISRA C:2023 Rule 13.6 - The operand of the sizeof operator shall not contain any expression which has potential side eﬀects
Supports MISRA C:2025 Rule 13.6
Supports MISRA C++:2008 Rule 5-3-4 - Evaluation of the operand to the sizeof operator shall not contain side eﬀects.

9007
note
side eﬀects on right hand of logical operator, 'string'
The right hand side of the || and && operators is only evaluated if the left hand side evaluates to a certain value. Consequently, code that expects the right hand side to be evaluated regardless of the left hand side can produce unanticipated results.
Supports AUTOSAR17 Rule M5-14-1
Supports AUTOSAR19 Rule M5-14-1
Supports CERT C EXP02-C - Be aware of the short-circuit behavior of the logical AND and OR operators
Supports CWE-768 - Incorrect Short Circuit Evaluation
Supports MISRA C 2004 Rule 12.4 - The right-hand operand of a logical && or || operator shall not contain side eﬀects.
Supports MISRA C 2012 Rule 13.5 - The right hand operand of a logical && or || operator shall not contain persistent side eﬀects
Supports MISRA C:2023 Rule 13.5 - The right hand operand of a logical && or || operator shall not contain persistent side eﬀects
Supports MISRA C:2025 Rule 13.5
Supports MISRA C++:2008 Rule 5-14-1 - The right hand operand of a logical && or || operator shall not contain side eﬀects.
Supports MISRA C++:2023 Rule 8.14.1 - The right-hand operand of a logical && or || operator should not contain persistent side eﬀects

9008
note
comma operator used
The comma operator is thought by some to reduce readability in code.
Supports MISRA C 2004 Rule 12.10 (Req) - The comma operator shall not be used.
Supports AUTOSAR17 Rule M5-18-1
Supports AUTOSAR19 Rule M5-18-1
Supports MISRA C 2004 Rule 12.10 - The comma operator shall not be used.
Supports MISRA C 2012 Rule 12.3 - The comma operator should not be used
Supports MISRA C:2023 Rule 12.3 - The comma operator should not be used
Supports MISRA C:2025 Rule 12.3
Supports MISRA C++:2008 Rule 5-18-1 - The comma operator shall not be used.
Supports MISRA C++:2023 Rule 8.19.1 - The comma operator should not be used

9009
note
possible use of ﬂoating point loop counter
The use of ﬂoating point variables as loop counters can produce surprising behavior if the accumulation of rounding errors results in a diﬀerent number of iterations than anticipated.
Supports AUTOSAR17 Rule A6-5-2
Supports AUTOSAR19 Rule A6-5-2
Supports CERT C FLP30-C - Do not use ﬂoating-point variables as loop counters
Supports MISRA C 2004 Rule 13.4 - The controlling expression of a for statement shall not contain any objects of ﬂoating type.
Supports MISRA C 2012 Rule 14.1 - A loop counter shall not have essentially ﬂoating type
Supports MISRA C:2023 Rule 14.1 - A loop counter shall not have essentially ﬂoating type
Supports MISRA C:2025 Rule 14.1
Supports MISRA C++:2008 Rule 6-5-1 - A for loop shall contain a single loop-counter which shall not have ﬂoating type.

9010
note
conversion from integer type type to pointer type type
An expression of integral type (other than a null pointer constant) was converted to a pointer type (other than void*).
Supports AUTOSAR17 Rule M5-2-8
Supports AUTOSAR19 Rule M5-2-8
Supports CWE-587 - Assignment of a Fixed Address to a Pointer
Supports MISRA C++:2008 Rule 5-2-8 - An object with integer type or pointer to void type shall not be converted to an object with pointer type.

9011
note
multiple loop exits
More than one break statement or goto statement is used to terminate a loop. Minimizing the number of exits from a loop is thought by some to reduce visual complexity of the code.
Supports MISRA C 2004 Rule 14.6 - For any iteration statement there shall be at most one break statement used for loop termination.
Supports MISRA C 2012 Rule 15.4 - There should be no more than one break or goto statement used to terminate any iteration statement
Supports MISRA C:2023 Rule 15.4 - There should be no more than one break or goto statement used to terminate any iteration statement
Supports MISRA C:2025 Rule 15.4
Supports MISRA C++:2008 Rule 6-6-4 - For any iteration statement there shall be no more than one break or goto statement used for loop termination.

9012
note
body 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.
Supports AUTOSAR17 Rule M6-3-1
Supports AUTOSAR17 Rule M6-4-1
Supports AUTOSAR19 Rule M6-3-1
Supports AUTOSAR19 Rule M6-4-1
Supports CERT C EXP19-C - Use braces for the body of an if, for, or while statement
Supports MISRA C 2004 Rule 14.8 - The statement forming the body of a switch, while, do ... while or for statement be a compound statement.
Supports MISRA C 2004 Rule 14.9 - An if (expression) construct shall be followed by a compound statement. The else keyword shall be followed by either a compound statement, or another if statement.
Supports MISRA C 2012 Rule 15.6 - The body of an iteration-statement or a selection-statement shall be a compound-statement
Supports MISRA C:2023 Rule 15.6 - The body of an iteration-statement or a selection-statement shall be a compound-statement
Supports MISRA C:2025 Rule 15.6
Supports MISRA C++:2008 Rule 6-3-1 - The statement forming the body of a switch, while, do ... while or for statement shall be a compound statement.
Supports MISRA C++:2008 Rule 6-4-1 - An if ( condition ) construct shall be followed by a compound statement. The else keyword shall be followed by either a compound statement, or another if statement.
Supports MISRA C++:2023 Rule 9.3.1 - The body of an iteration-statement or a selection-statement shall be a compound-statement

9013
note
no 'else' at end of 'if ... else if' chain
An if...else if chain was seen without a ﬁnal else statement. Providing such a statement helps to act as an analog to the default case of a switch-statement.
Supports AUTOSAR17 Rule M6-4-2
Supports AUTOSAR19 Rule M6-4-2
Supports CERT C MSC01-C - Strive for logical completeness
Supports MISRA C 2004 Rule 14.10 - All if ... else if constructs shall be terminated with an else clause.
Supports MISRA C 2012 Rule 15.7 - All if ... else if constructs shall be terminated with an else statement
Supports MISRA C:2023 Rule 15.7 - All if ... else if constructs shall be terminated with an else statement
Supports MISRA C:2025 Rule 15.7
Supports MISRA C++:2008 Rule 6-4-2 - All if ... else if constructs shall be terminated with an else clause.
Supports MISRA C++:2023 Rule 9.4.1 - All if ... else if constructs shall be terminated with an else statement

9014
note
switch without default
A switch-statement was found without a default case. Providing such a case provides defensive programming.
Supports MISRA C 2004 Rule 15.3 - The ﬁnal clause of a switch statement shall be the default clause.
Supports MISRA C 2012 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C 2012 Rule 16.4 - Every switch statement shall have a default label
Supports MISRA C:2023 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C:2023 Rule 16.4 - Every switch statement shall have a default label
Supports MISRA C:2025 Rule 16.1
Supports MISRA C:2025 Rule 16.4

9015
note
macro 'name' appearing in argument integer of macro 'name' is used both with and without '#/##' and is subject to further replacement
In the expansion of a function-like macro, a macro argument was used both as an operand to the stringizing or pasting operators and was also used in a way in which it was subject to further macro replacement. For example:

#define M1 123 
#define FM(x) ident_ ## x + x 
... 
FM(10);    // Okay, 10 is not a macro 
FM(M1);    // 9015, M1 both expanded and used with ##

The FM macro uses the parameter x as an operand to the token pasting operator (where a macro argument would not be expanded) and in a context where a macro argument would be expanded. This example expands to:

ident_10 + 10; 
ident_M1 + 123;

In the second invocation, part of the expansion contains the unexpanded macro and another contains the result of the expanded macro argument. This may be confusing and lead to unexpected results.
Supports MISRA C 2012 Rule 20.12 - A macro parameter used as an operand to the # or ## operators, which is itself subject to further macro replacement, shall only be used as an operand to these operators
Supports MISRA C:2023 Rule 20.12 - A macro parameter used as an operand to the # or ## operators, which is itself subject to further macro replacement, shall only be used as an operand to these operators
Supports MISRA C:2025 Rule 20.12
Supports MISRA C++:2023 Rule 19.3.3 - The argument to a mixed-use macro parameter shall not be subject to further expansion

9016
note
performing pointer arithmetic via addition/subtraction
Array indexing is thought, by some, to be more readily understood and less error prone than other forms of pointer arithmetic.
Supports AUTOSAR17 Rule M5-0-15
Supports AUTOSAR19 Rule M5-0-15
Supports MISRA C 2004 Rule 17.4 - Array indexing shall be the only allowed form of pointer arithmetic.
Supports MISRA C 2012 Rule 18.4 - The +, -, += and -= operators should not be applied to an expression of pointer type
Supports MISRA C:2023 Rule 18.4 - The +, -, += and -= operators should not be applied to an expression of pointer type
Supports MISRA C:2025 Rule 18.4
Supports MISRA C++:2008 Rule 5-0-15 - Array indexing shall be the only form of pointer arithmetic.

9017
note
incrementing/decrementing pointer
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 message 9016 and placed under this one, allowing a more ﬁne tuning of Lint diagnostics.
Supports MISRA C 2004 Rule 17.4 - Array indexing shall be the only allowed form of pointer arithmetic.

9018
note
union symbol declared
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 unspeciﬁed, undeﬁned, or implementation deﬁned behavior, prompting some to advise against their use.
Supports AUTOSAR17 Rule M9-5-1
Supports AUTOSAR19 Rule A9-5-1
Supports MISRA C 2004 Rule 18.4 - Unions shall not be used.
Supports MISRA C 2012 Rule 19.2 - The union keyword should not be used
Supports MISRA C:2023 Rule 19.2 - The union keyword should not be used
Supports MISRA C:2025 Rule 19.2
Supports MISRA C++:2008 Rule 9-5-1 - Unions shall not be used.

9019
note
declaration of symbol 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 risk of undeﬁned behavior resulting from any use of the ISO standard library before the relevant #include directive.
Supports AUTOSAR17 Rule M16-0-1
Supports AUTOSAR19 Rule M16-0-1
Supports MISRA C 2004 Rule 19.1 - #include statements in a ﬁle should only be preceded by other preprocessor directives or comments.
Supports MISRA C 2012 Rule 20.1 - #include directives should only be preceded by preprocessor directives or comments
Supports MISRA C:2023 Rule 20.1 - #include directives should only be preceded by preprocessor directives or comments
Supports MISRA C:2025 Rule 20.1
Supports MISRA C++:2008 Rule 16-0-1 - #include directives in a ﬁle shall only be preceded by other preprocessor directives or comments.
Supports MISRA C++:2023 Rule 19.0.3 - #include directives should only be preceded by preprocessor directives or comments

9020
note
header ﬁle name 'string' contains non-standard character 'string'
This message is issued when one of the characters ’, ", or \ or one of the character sequences /* or // appears in the header name speciﬁed by a #include directive. The behavior of these characters in a #include directive is undeﬁned in C and implementation-deﬁned in C++.
Supports AUTOSAR17 Rule A16-2-1
Supports AUTOSAR19 Rule A16-2-1
Supports MISRA C 2004 Rule 19.2 - Non-standard characters should not occur in header ﬁle names in #include directives.
Supports MISRA C 2012 Rule 20.2 - The ‘, " or \ characters and the /* or // character sequences shall not occur in a header ﬁle name
Supports MISRA C:2023 Rule 20.2 - The ‘, " or \ characters and the /* or // character sequences shall not occur in a header ﬁle name
Supports MISRA C:2025 Rule 20.2
Supports MISRA C++:2008 Rule 16-2-4 - The ‘, ", /* or // characters shall not occur in a header ﬁle name.
Supports MISRA C++:2008 Rule 16-2-5 - The \ character should not occur in a header ﬁle name.
Supports MISRA C++:2023 Rule 19.2.3 - The ‘ or " or \ characters and the /* or // character sequences shall not occur in a header ﬁle name

9021
note
use of '#undef' is discouraged: 'detail'
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.
Supports AUTOSAR17 Rule A16-0-1
Supports AUTOSAR19 Rule A16-0-1
Supports MISRA C 2004 Rule 19.6 - #undef shall not be used.
Supports MISRA C 2012 Rule 20.5 - #undef should not be used
Supports MISRA C:2023 Rule 20.5 - #undef should not be used
Supports MISRA C:2025 Rule 20.5
Supports MISRA C++:2008 Rule 16-0-3 - #undef shall not be used.

9022
note
unparenthesized macro parameter 'string' in deﬁnition of macro 'string' 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.
Supports AUTOSAR17 Rule M16-0-6
Supports AUTOSAR19 Rule M16-0-6
Supports CERT C PRE01-C - Use parentheses within macros around parameter names
Supports MISRA C 2004 Rule 19.10 - In the deﬁnition of a function-like macro each instance of a parameter shall be enclosed in parentheses unless it is used as the operand of # or ##.
Supports MISRA C++:2008 Rule 16-0-6 - In the deﬁnition of a function-like macro, each instance of a parameter shall be enclosed in parentheses, unless it is used as the operand of # or ##.

9023
note
multiple use of stringize/pasting operators in deﬁnition of macro name
Multiple use of such operators is thought by some to increase risk of undeﬁned behavior.
Supports AUTOSAR17 Rule M16-3-1
Supports AUTOSAR19 Rule M16-3-1
Supports MISRA C 2004 Rule 19.12 - There shall be at most one occurrence of the # or ## preprocessor operators in a single macro deﬁnition.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3
Supports MISRA C++:2008 Rule 16-3-1 - There shall be at most one occurrence of the # or ## operators in a single macro deﬁnition.

9024
note
pasting/stringize operator used in deﬁnition of object-like/function-like macro 'string'
The use of token pasting (##) and stringizing (#) preprocessor operators is thought by some to reduce code clarity and increase the risk of undeﬁned behavior.
Supports AUTOSAR17 Rule M16-3-2
Supports AUTOSAR19 Rule M16-3-2
Supports CERT C PRE05-C - Understand macro replacement when concatenating tokens or performing stringiﬁcation
Supports MISRA C 2004 Rule 19.13 - The # and ## preprocessor operators should not be used.
Supports MISRA C 2012 Rule 20.10 - The # and ## preprocessor operators should not be used
Supports MISRA C:2023 Rule 20.10 - The # and ## preprocessor operators should not be used
Supports MISRA C:2025 Rule 20.10
Supports MISRA C++:2008 Rule 16-3-2 - The # and ## operators should not be used.
Supports MISRA C++:2023 Rule 19.3.1 - The # and ## preprocessor operators should not be used

9025
note
more than two levels of pointer indirection
Three or more levels of pointer indirection may make it harder to understand the code.
Supports AUTOSAR17 Rule A5-0-3
Supports AUTOSAR19 Rule A5-0-3
Supports MISRA C 2004 Rule 17.5 - The declaration of objects should contain no more than 2 levels of pointer indirection.
Supports MISRA C 2012 Rule 18.5 - Declarations should contain no more than two levels of pointer nesting
Supports MISRA C:2023 Rule 18.5 - Declarations should contain no more than two levels of pointer nesting
Supports MISRA C:2025 Rule 18.5
Supports MISRA C++:2008 Rule 5-0-19 - The declaration of objects shall contain no more than two levels of pointer indirection.
Supports MISRA C++:2023 Rule 11.3.2 - The declaration of an object should contain no more than two levels of pointer indirection

9026
note
function-like macro, 'macro', deﬁned
Multiple authors have expressed reasons why a function, when possible, should be used in place of a function-like macro.
Supports AUTOSAR17 Rule A16-0-1
Supports AUTOSAR19 Rule A16-0-1
Supports CERT C PRE00-C - Prefer inline or static functions to function-like macros
Supports MISRA C 2004 Rule 19.7 - A function should be used in preference to a function-like macro.
Supports MISRA C 2012 Dir 4.9 - A function should be used in preference to a function-like macro where they are interchangeable
Supports MISRA C:2023 Dir 4.9 - A function should be used in preference to a function-like macro where they are interchangeable
Supports MISRA C:2025 Dir 4.9
Supports MISRA C++:2008 Rule 16-0-4 - Function-like macros shall not be deﬁned.
Supports MISRA C++:2023 Rule 19.0.2 - Function-like macros shall not be deﬁned

9027
note
essential-type value is not an appropriate string operand to operator
Out of concern for unspeciﬁed, undeﬁned, and/or implementation deﬁned behavior, some standards urge restrictions on certain types of operands when used with certain operators.
Supports MISRA C 2012 Rule 10.1 - Operands shall not be of an inappropriate essential type
Supports MISRA C:2023 Rule 10.1 - Operands shall not be of an inappropriate essential type
Supports MISRA C:2025 Rule 10.1

9028
note
essential-type value is not an appropriate string operand to operator
MISRA C 2012 has deﬁned the concept of essentially character type and placed restrictions on the use of expressions with such a type.
Supports MISRA C 2012 Rule 10.2 - Expressions of essentially character type shall not be used inappropriately in addition and subtraction operations
Supports MISRA C:2023 Rule 10.2 - Expressions of essentially character type shall not be used inappropriately in addition and subtraction operations
Supports MISRA C:2025 Rule 10.2

9029
note
essential-type value and essential-type value cannot be used together as operands to operator
MISRA C 2012 has deﬁned the concept of essentially type and placed restrictions on the use of expressions with certain types with respect to binary operators.
Supports MISRA C 2012 Rule 10.4 - Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category
Supports MISRA C:2023 Rule 10.4 - Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category
Supports MISRA C:2025 Rule 10.4

9030
note
cannot cast essential-type value to essential-type type
MISRA C 2012 has deﬁned the concept of essential type and placed restrictions on the use of casts between certain types.
Supports MISRA C 2012 Rule 10.5 - The value of an expression should not be cast to an inappropriate essential type
Supports MISRA C:2023 Rule 10.5 - The value of an expression should not be cast to an inappropriate essential type
Supports MISRA C:2025 Rule 10.5

9031
note
cannot assign a composite expression of type 'essential-type' to an object of wider type 'essential-type'
MISRA C 2012 has deﬁned the concepts of composite expression and essential type and placed restrictions on assignments of the former.
Supports MISRA C 2012 Rule 10.6 - The value of a composite expression shall not be assigned to an object with wider essential type
Supports MISRA C:2023 Rule 10.6 - The value of a composite expression shall not be assigned to an object with wider essential type
Supports MISRA C:2025 Rule 10.6

9032
note
left/right operand to operator is a composite expression of type 'essential-type' which is smaller than the left/right operand of type 'essential-type'
MISRA C 2012 has deﬁned 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 deﬁnition of the former concept.
Supports MISRA C 2012 Rule 10.7 - If a composite expression is used as one operand of an operator in which the usual arithmetic conversions are performed then the other operand shall not have wider essential type
Supports MISRA C:2023 Rule 10.7 - If a composite expression is used as one operand of an operator in which the usual arithmetic conversions are performed then the other operand shall not have wider essential type
Supports MISRA C:2025 Rule 10.7

9033
note
cannot cast 'essential-type' to wider/diﬀerent essential type 'essential-type'
MISRA C 2012 has deﬁned 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".
Supports MISRA C 2012 Rule 10.8 - The value of a composite expression shall not be cast to a diﬀerent essential type category or a wider essential type
Supports MISRA C:2023 Rule 10.8 - The value of a composite expression shall not be cast to a diﬀerent essential type category or a wider essential type
Supports MISRA C:2025 Rule 10.8

9034
note
cannot assign 'essential-type' to narrow/diﬀerent essential type 'essential-type'
MISRA C 2012 has deﬁned the concept of essential type and placed restrictions on assignments in relation to such types.
Supports MISRA C 2012 Rule 10.3 - The value of an expression shall not be assigned to an object with a narrower essential type or of a diﬀerent essential type category
Supports MISRA C:2023 Rule 10.3 - The value of an expression shall not be assigned to an object with a narrower essential type or of a diﬀerent essential type category
Supports MISRA C:2025 Rule 10.3

9035
note
variable length array of type type declared
Variable length arrays can introduce unspeciﬁed behavior and runtime-dependent undeﬁned behavior. As of C11 it is not required that implementations support this feature. For these reasons, the use of VLAs is often discouraged.
Supports CERT C ARR32-C - Ensure size arguments for variable length arrays are in a valid range
Supports CERT C MEM05-C - Avoid large stack allocations
Supports CWE-758 - Reliance on Undeﬁned, Unspeciﬁed, or Implementation-Deﬁned Behavior
Supports MISRA C 2004 Rule 1.1 - All code shall conform to ISO 9899:1990 "Programming languages - C", amended and corrected by ISO/IEC 9899/COR1:1995, ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/COR2:1996.
Supports MISRA C 2012 Rule 18.8 - Variable-length array types shall not be used
Supports MISRA C:2023 Rule 18.8 - Variable-length array types shall not be used
Supports MISRA C:2025 Rule 18.8

9036
note
essential type of condition of 'do/for/if/while' statement is 'essential-type' but should be boolean
MISRA C 2012 has deﬁned the concept of essentially Boolean type and requires the conditional expressions of all if and iteration-statements comply with this deﬁnition.
Supports MISRA C 2012 Rule 14.4 - The controlling expression of an if statement and the controlling expression of an iteration-statement shall have essentially Boolean type
Supports MISRA C:2023 Rule 14.4 - The controlling expression of an if statement and the controlling expression of an iteration-statement shall have essentially Boolean type
Supports MISRA C:2025 Rule 14.4

9037
note
conditional of #if/#elif does not evaluate to 0 or 1
Some urge such a practice in the interest of strong typing.
Supports MISRA C 2012 Rule 20.8 - The controlling expression of a #if or #elif preprocessing directive shall evaluate to 0 or 1
Supports MISRA C:2023 Rule 20.8 - The controlling expression of a #if or #elif preprocessing directive shall evaluate to 0 or 1
Supports MISRA C:2025 Rule 20.8

9038
note
ﬂexible array member declared
Flexible array members can alter the behavior of sizeof in surprising ways. Additionally, ﬂexible array members often require dynamic memory allocation, which may be problematic in safety critical code.
Supports MISRA C 2012 Rule 18.7 - Flexible array members shall not be declared
Supports MISRA C:2023 Rule 18.7 - Flexible array members shall not be declared
Supports MISRA C:2025 Rule 18.7

9039
note
potentially confusing hexadecimal/octal escape sequence usage
An octal or hexadecimal escape sequence has been detected within a string or character literal that is not immediately followed by another escape sequence or end of literal.
Supports MISRA C 2012 Rule 4.1 - Octal and hexadecimal escape sequences shall be terminated
Supports MISRA C:2023 Rule 4.1 - Octal and hexadecimal escape sequences shall be terminated
Supports MISRA C:2025 Rule 4.1
Supports MISRA C++:2023 Rule 5.13.2 - Octal escape sequences, hexadecimal escape sequences and universal character names shall be terminated

9040
note
possible struct hack declaration for detail member symbol with integer element(s)
Prior to C99 adding ﬂexible array members, the now obsolete struct hack technique was widely used to create structures who’s last member was an array with variable length. In addition, some compilers also allowed this technique to create variable length array members within unions. The technique required the variable length member array(s) to be declared with a size of either 0 or 1 within the declaration of the structure or union.

struct S { 
 int a; 
 int b[0];    // warning 9040 
}; 
 
union U { 
 int   a; 
 short  b[1];  // warning 9040 
 char  c[1];  // warning 9040 
 double d; 
};

Supports CERT C DCL38-C - Use the correct syntax when declaring a ﬂexible array member

9041
note
goto appears in block string which is not nested in block string which contains label symbol
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 in the blocks using an identiﬁcation code (e.g. "1.2.1"). This identiﬁcation scheme is deﬁned as follows:

1.: The outer block has an identiﬁcation of 1.
2.: If a particular block is identiﬁed by x then its immediate subblocks, if any, are identiﬁed as x.1, x.2, x.3, etc.

Thus in the following ’code’,

{ { } {{label: } { } } }

label lies in block 1.2.1.
Supports AUTOSAR17 Rule M6-6-1
Supports AUTOSAR19 Rule M6-6-1
Supports MISRA C 2012 Rule 15.3 - Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement
Supports MISRA C:2023 Rule 15.3 - Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement
Supports MISRA C:2025 Rule 15.3
Supports MISRA C++:2008 Rule 6-6-1 - Any label referenced by a goto statement shall be declared in the same block, or in a block enclosing the goto statement.
Supports MISRA C++:2023 Rule 9.6.2 - A goto statement shall reference a label in a surrounding block

9042
note
departure from MISRA switch syntax: detail
A switch-statement was found that does not comply with the MISRA switch-statement syntax. detail contains a description of the departure.
Supports AUTOSAR17 Rule M6-4-3
Supports AUTOSAR19 Rule M6-4-3
Supports MISRA C 2004 Rule 15.0 - The preamble normative text in section 15 shall be treated as Rule 15.0.
Supports MISRA C 2012 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C:2023 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C:2025 Rule 16.1
Supports MISRA C++:2008 Rule 6-4-3 - A switch statement shall be a well-formed switch statement.

9043
note
static keyword between brackets of array declaration
Some advocate against using the keyword static in array declarations due to a perceived increased risk of undeﬁned behavior.
Supports MISRA C 2012 Rule 17.6 - The declaration of an array parameter shall not contain the static keyword between the [ ]
Supports MISRA C:2023 Rule 17.6 - The declaration of an array parameter shall not contain the static keyword between the [ ]

9044
note
function parameter symbol modiﬁed
It has been advocated that function parameters be ﬁrst copied to local variables where they can be modiﬁed rather than modifying the parameters directly.
Supports MISRA C 2012 Rule 17.8 - A function parameter should not be modiﬁed
Supports MISRA C:2023 Rule 17.8 - A function parameter should not be modiﬁed
Supports MISRA C:2025 Rule 17.8

9045
note
complete deﬁnition of symbol is unnecessary in this translation unit
Some advise against including structure deﬁnitions unless the deﬁnition is required for the current module.
Supports MISRA C 2012 Dir 4.8 - If a pointer to a structure or union is never dereferenced within a translation unit, then the implementation of the object should be hidden
Supports MISRA C:2023 Dir 4.8 - If a pointer to a structure or union is never dereferenced within a translation unit, then the implementation of the object should be hidden
Supports MISRA C:2025 Dir 4.8

9046
note
symbol is typographically ambiguous with respect to 'string' when detail
Some have warned against the use of identiﬁers that may be considered typographically ambiguous. In addition to the name of the previously seen symbol, the reasons Lint considers the identiﬁers to be ambiguous and the location of said previous symbol are provided in the message, if available.
Supports CERT C DCL02-C - Use visually distinct identiﬁers
Supports MISRA C 2012 Dir 4.5 - Identiﬁers in the same name space with overlapping visibility should be typographically unambiguous
Supports MISRA C:2023 Dir 4.5 - Identiﬁers in the same name space with overlapping visibility should be typographically unambiguous
Supports MISRA C:2025 Dir 4.5

9047
note
FILE pointer dereferenced
At least one standards organization urges against this practice, directly or indirectly.
Supports CERT C FIO38-C - Do not copy a FILE object
Supports MISRA C 2012 Rule 22.5 - A pointer to a FILE object shall not be dereferenced
Supports MISRA C:2023 Rule 22.5 - A pointer to a FILE object shall not be dereferenced
Supports MISRA C:2025 Rule 22.5

9048
note
unsigned integer literal without a 'U' suﬃx
An integer literal of unsigned type was found without a ’U’ suﬃx.
Supports MISRA C 2004 Rule 10.6 - A "U" suﬃx shall be applied to all constants of unsigned type.
Supports MISRA C 2012 Rule 7.2 - A "u" or "U" suﬃx shall be applied to all integer constants that are represented in an unsigned type
Supports MISRA C:2023 Rule 7.2 - A "u" or "U" suﬃx shall be applied to all integer constants that are represented in an unsigned type
Supports MISRA C:2025 Rule 7.2
Supports MISRA C++:2023 Rule 5.13.4 - Unsigned integer literals shall be appropriately suﬃxed

9049
note
increment/decrement operation combined with other operation with side-eﬀects
An expression was seen involving an increment or decrement operator and the expression also contained potential side-eﬀects other than those resulting from said operator. For the purpose of this message, a function call is always considered to have potential side-eﬀects.
Supports AUTOSAR17 Rule M5-2-10
Supports AUTOSAR19 Rule M5-2-10
Supports MISRA C 2004 Rule 12.13 - The increment (++) and decrement (–) operators should not be mixed with other operators in an expression.
Supports MISRA C 2012 Rule 13.3 - A full expression containing an increment (++) or decrement (–) operator should have no other potential side eﬀects other than that caused by the increment or decrement operator
Supports MISRA C:2023 Rule 13.3 - A full expression containing an increment (++) or decrement (–) operator should have no other potential side eﬀects other than that caused by the increment or decrement operator
Supports MISRA C:2025 Rule 13.3
Supports MISRA C++:2008 Rule 5-2-10 - The increment (++) and decrement (–) operators should not be mixed with other operators in an expression.

9050
note
dependence placed on operator precedence (operators 'operator' and 'operator')
Reliance on operator precedence was found in a particular expression. Using parentheses, it is felt, helps clarify the order of evaluation.
Supports MISRA C 2004 Rule 12.1 (Adv) - Limited dependence should be placed on C’s operator precedence rules in expressions.
Supports CERT C EXP00-C - Use parentheses for precedence of operation
Supports CWE-783 - Operator Precedence Logic Error
Supports MISRA C 2004 Rule 12.1 - Limited dependence should be placed on C’s operator precedence rules in expressions.
Supports MISRA C 2012 Rule 12.1 - The precedence of operators within expressions should be made explicit
Supports MISRA C:2023 Rule 12.1 - The precedence of operators within expressions should be made explicit
Supports MISRA C:2025 Rule 12.1
Supports MISRA C++:2023 Rule 8.0.1 - Parentheses should be used to make the meaning of an expression appropriately explicit

9051
note
macro 'string' deﬁned with the same name as a C keyword
A macro was deﬁned with the same name as an ISO C keyword. The use of such a macro causes undeﬁned behavior.
Supports MISRA C 2012 Rule 20.4 - A macro shall not be deﬁned with the same name as a keyword
Supports MISRA C:2023 Rule 20.4 - A macro shall not be deﬁned with the same name as a keyword
Supports MISRA C:2025 Rule 20.4

9052
note
macro 'string' deﬁned with the same name as a C++ keyword
A macro was deﬁned with the same name as an ISO C++ keyword. The use of such a macro causes undeﬁned behavior.

Supports MISRA C++:2008 Rule 17-0-1 - Reserved identiﬁers, macros and functions in the standard library shall not be deﬁned, redeﬁned or undeﬁned.

9053
note
the shift value is negative/at least the precision of the left hand side
A quantity with a certain essential type, as deﬁned by MISRA, was shifted by a number less than zero or exceeding the number of bits used to represent that essential type.
Supports MISRA C 2012 Rule 12.2 - The right hand operand of a shift operator shall lie in the range zero to one less than the width in bits of the essential type of the left hand operand
Supports MISRA C:2023 Rule 12.2 - The right hand operand of a shift operator shall lie in the range zero to one less than the width in bits of the essential type of the left hand operand
Supports MISRA C:2025 Rule 12.2

9054
note
designated initializer used with array of unspeciﬁed dimension
It has been advocated, when arrays 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.
Supports MISRA C 2012 Rule 9.5 - Where designated initializers are used to initialize an array object the size of the array shall be speciﬁed explicitly
Supports MISRA C:2023 Rule 9.5 - Where designated initializers are used to initialize an array object the size of the array shall be speciﬁed explicitly
Supports MISRA C:2025 Rule 9.5

9055
note
most closely enclosing compound statement of this 'string' label is not a switch statement
Labels nested inside of compound statements within the corresponding switch are legal but can reduce comprehension and lead to unstructured code.
Supports AUTOSAR17 Rule M6-4-4
Supports AUTOSAR19 Rule M6-4-4
Supports CERT C MSC20-C - Do not use a switch statement to transfer control into a complex block
Supports MISRA C 2004 Rule 15.1 - A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement.
Supports MISRA C 2012 Rule 16.2 - A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement
Supports MISRA C:2023 Rule 16.2 - A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement
Supports MISRA C:2025 Rule 16.2
Supports MISRA C++:2008 Rule 6-4-4 - A switch-label shall only be used when the most closely-enclosing compound statement is the body of a switch statement.

9056
note
inline function symbol deﬁned with storage-class speciﬁer string
This message is issued for all inline functions deﬁned with a storage-class speciﬁer. +estring can be used to ﬁnd all inline functions deﬁned with a speciﬁc speciﬁer. For example, +estring(9056, extern) will report all inline functions deﬁned with extern.
Supports MISRA C 2012 Rule 8.10 - An inline function shall be declared with the static storage class
Supports MISRA C:2023 Rule 8.10 - An inline function shall be declared with the static storage class
Supports MISRA C:2025 Rule 8.10

9057
note
lowercase L follows 'u' in literal suﬃx
A lowercase letter "l" is used inside of a literal suﬃx 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).
Supports MISRA C 2012 Rule 7.3 - The lowercase character "l" shall not be used in a literal suﬃx
Supports MISRA C:2023 Rule 7.3 - The lowercase character "l" shall not be used in a literal suﬃx
Supports MISRA C:2025 Rule 7.3

9058
note
tag symbol 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. This message is suppressed for unit checkout (-unit_check option).
Supports MISRA C 2012 Rule 2.4 - A project should not contain unused tag declarations
Supports MISRA C:2023 Rule 2.4 - A project should not contain unused tag declarations
Supports MISRA C:2025 Rule 2.4

9059
note
C comment contains C++ comment
A C++-style comment was seen inside a C-style comment. This can be confusing.
Supports CERT C MSC04-C - Use comments consistently and in a readable fashion
Supports MISRA C 2012 Rule 3.1 - The character sequences /* and // shall not be used within a comment
Supports MISRA C:2023 Rule 3.1 - The character sequences /* and // shall not be used within a comment
Supports MISRA C:2025 Rule 3.1

9060
note
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.
Supports CERT C PRE07-C - Avoid using repeated question marks
Supports CERT C MSC04-C - Use comments consistently and in a readable fashion
Supports MISRA C 2012 Rule 4.2 - Trigraphs should not be used
Supports MISRA C:2023 Rule 4.2 - Trigraphs should not be used
Supports MISRA C:2025 Rule 4.2
Supports MISRA C++:2023 Rule 5.0.1 - Trigraph-like sequences should not be used

9063
note
no comment or action in the 'else' that terminates 'if ... else if' chain
An else-branch was seen that contained neither a comment nor an actionable statement. At least one standards organization cautions against such "empty else" branches.
Supports MISRA C 2004 Rule 14.10 - All if ... else if constructs shall be terminated with an else clause.
Supports MISRA C 2012 Rule 15.7 - All if ... else if constructs shall be terminated with an else statement
Supports MISRA C:2023 Rule 15.7 - All if ... else if constructs shall be terminated with an else statement
Supports MISRA C:2025 Rule 15.7

9064
note
goto references earlier label symbol
A goto makes reference to a label appearing earlier in the code. At least one author recommends all such statements reference points later in the code in an attempt to reduce visual code complexity.
Supports AUTOSAR17 Rule M6-6-2
Supports AUTOSAR19 Rule M6-6-2
Supports MISRA C 2012 Rule 15.2 - The goto statement shall jump to a label declared later in the same function
Supports MISRA C:2023 Rule 15.2 - The goto statement shall jump to a label declared later in the same function
Supports MISRA C:2025 Rule 15.2
Supports MISRA C++:2008 Rule 6-6-2 - The goto statement shall jump to a label declared later in the same function body.
Supports MISRA C++:2023 Rule 9.6.3 - The goto statement shall jump to a label declared later in the function body

9066
note
C++ comment contains C comment
A C-style comment was seen inside a C++-style comment. This can result in confusion.
Supports CERT C MSC04-C - Use comments consistently and in a readable fashion
Supports MISRA C 2012 Rule 3.1 - The character sequences /* and // shall not be used within a comment
Supports MISRA C:2023 Rule 3.1 - The character sequences /* and // shall not be used within a comment
Supports MISRA C:2025 Rule 3.1

9067
note
extern array declared without size or initializer
An array was declared without a dimension. At least one standards organization advises against such a practice in the interest of safety. Note this message is not given if the array is initialized at the time of declaration.
Supports AUTOSAR17 Rule A3-1-4
Supports AUTOSAR19 Rule A3-1-4
Supports MISRA C 2004 Rule 8.12 - When an array is declared with external linkage, its size shall be stated explicitly or deﬁned implicitly by initialisation.
Supports MISRA C 2012 Rule 8.11 - When an array with external linkage is declared, its size should be explicitly speciﬁed
Supports MISRA C:2023 Rule 8.11 - When an array with external linkage is declared, its size should be explicitly speciﬁed
Supports MISRA C:2025 Rule 8.11
Supports MISRA C++:2008 Rule 3-1-3 - When an array is declared, its size shall either be stated explicitly or deﬁned implicitly by initialization.
Supports MISRA C++:2023 Rule 6.0.2 - When an array with external linkage is declared, its size should be explicitly speciﬁed

9068
note
partial array initialization
An array has been initialized only partly. Providing an explicit initialization for each element of an array makes it clear every element has been considered. This diagnostic is not issued if the array is initialized with a {0} initializer or if the initializer consists entirely of designated initializers or if the array is initialized using a string literal. See also 785 .

Supports MISRA C 2004 Rule 9.2 - Braces shall be used to indicate and match the structure in the non-zero initialisation of arrays and structures.
Supports MISRA C 2012 Rule 9.3 - Arrays shall not be partially initialized
Supports MISRA C:2023 Rule 9.3 - Arrays shall not be partially initialized
Supports MISRA C:2025 Rule 9.3

9069
note
in initializer for symbol symbol, initializer of type type needs braces or designator
In the initializer for a variable declared with aggregate (array or structure) or union type, there were insuﬃcient braces or designators necessary to make clear which members/elements are initialized to which values. More speciﬁcally, the initializer is expected to be fully braced, e.g. with braces appearing at the beginning of every aggregate sub-object being explicitly initialized, with the following exceptions:

If all of the initializers for a particular sub-object are designated initializers, braces are not required for that sub-object.
String literals may be used to initialize arrays.
An aggregate sub-object may be initialized with an object of compatible type.
The idiomatic { 0 } may be used to initialize sub-objects to an arbitrary depth without providing nested braces.

For example:

enum wk_type { FIRE, ICE }; 
 
struct monster { 
   const char name[10]; 
   int hp; 
   struct weakness { 
      enum wk_type wk; 
      double dmg_mult; 
   } weak[2]; 
}; 
 
// Okay - all initialized sub-objects are braced, array 'name' initialized with string literal 
struct monster goblin1 = {"goblin", 10, {{ICE, 2.0}, {FIRE, 1.5}}}; 
 
// 9069 - the second element of the 'weak' array is not braced 
struct monster goblin2 = {"goblin", 10, {{ICE, 2.0}, FIRE, 1.5}}; 
 
// Okay - only initialized part of non-braced sub-object uses designated initializer 
struct monster goblin3 = {"goblin", 20, .weak[0].wk = FIRE}; 
 
// 9069 - '1' initializes part of sub-object that is not braced 
struct monster goblin4 = {"goblin", 10, .weak[0].wk = FIRE, 1}; 
 
// 9069 - initialized sub-object 'struct weakness [0]' needs additional braces 
struct monster goblin5 = {"goblin", 40, {1}}; 
 
// Okay - exception for sub-objects initialized with { 0 } 
struct monster goblin6 = {"goblin", 40, {0}};

Supports MISRA C 2012 Rule 9.2 - The initializer for an aggregate or union shall be enclosed in braces
Supports MISRA C:2023 Rule 9.2 - The initializer for an aggregate or union shall be enclosed in braces
Supports MISRA C:2025 Rule 9.2

9070
note
function symbol is recursive
The named function has been found to potentially call itself, either directly or indirectly.

void fn() { fn(); }  // note 9070

Recursion carries with it the danger of exceeding available stack space, which can lead to a run-time failure. All else being equal, the more that recursion is constrained, the easier determining the worst-case stack usage can be.

This message will be emitted at the location of the function during global wrap-up. If global wrap-up is disabled, for example by using the -unit_check option, then the message will be emitted at the end of processing without a location. Since there is no location information available in this mode, this message will need to be enabled globally, outside of the module and on the command line or in an Indirect ﬁle, to be emitted.
Supports AUTOSAR17 Rule A7-5-2
Supports AUTOSAR19 Rule A7-5-2
Supports CERT C MEM05-C - Avoid large stack allocations
Supports MISRA C 2004 Rule 16.2 - Functions shall not call themselves, either directly or indirectly.
Supports MISRA C 2012 Rule 17.2 - Functions shall not call themselves, either directly or indirectly
Supports MISRA C:2023 Rule 17.2 - Functions shall not call themselves, either directly or indirectly
Supports MISRA C:2025 Rule 17.2
Supports MISRA C++:2008 Rule 7-5-4 - Functions should not call themselves, either directly or indirectly.
Supports MISRA C++:2023 Rule 8.2.10 - Functions shall not call themselves, either directly or indirectly

9071
note
deﬁned macro 'name' is reserved to the compiler
A macro was deﬁned that is reserved to the compiler. Such deﬁnition results in undeﬁned behavior.
Supports CERT C DCL37-C - Do not declare or deﬁne a reserved identiﬁer
Supports MISRA C 2004 Rule 20.1 - Reserved identiﬁers, macros and functions in the standard library, shall not be deﬁned, redeﬁned or undeﬁned.
Supports MISRA C 2012 Rule 21.1 - #deﬁne and #undef shall not be used on a reserved identiﬁer or reserved macro name
Supports MISRA C:2023 Rule 21.1 - #deﬁne and #undef shall not be used on a reserved identiﬁer or reserved macro name
Supports MISRA C:2025 Rule 20.15
Supports MISRA C++:2008 Rule 17-0-1 - Reserved identiﬁers, macros and functions in the standard library shall not be deﬁned, redeﬁned or undeﬁned.

9072
note
parameter integer of function symbol has diﬀerent name than previous declaration (symbol vs symbol)
The parameter of function symbol speciﬁed by integer has a parameter name that diﬀers from the name of a previous declaration of the same function. Using inconsistent names within declarations of the same function can be confusing and result in misuse.
Supports AUTOSAR17 Rule M8-4-2
Supports AUTOSAR19 Rule M8-4-2
Supports MISRA C 2004 Rule 16.4 - The identiﬁers used in the declaration and deﬁnition of a function shall be identical.
Supports MISRA C 2012 Rule 8.3 - All declarations of an object or function shall use the same names and type qualiﬁers
Supports MISRA C:2023 Rule 8.3 - All declarations of an object or function shall use the same names and type qualiﬁers
Supports MISRA C:2025 Rule 8.3
Supports MISRA C++:2008 Rule 8-4-2 - The identiﬁers used for the parameters in a re-declaration of a function shall be identical to those in the declaration.
Supports MISRA C++:2023 Rule 13.3.3 - The parameters in all declarations or overrides of a function shall either be unnamed or have identical names

9073
note
parameter integer of function symbol has type alias name type diﬀerence with previous declaration (type vs type)
In a function declaration or deﬁnition, the speciﬁed parameter is declared with a type that, while technically identical, uses a diﬀerent name for the type than was used for the parameter in a previous declaration. For example:

typedef int INT; 
void foo(int i); 
void foo(INT i) { 
   ... 
}

would yield this message as the parameter i in function foo is declared as an int in both cases but in the deﬁnition the typedef name INT is used while in the preceding declaration the name INT is not employed. Such inconsistencies can result in unnecessary confusion.
Supports AUTOSAR17 Rule M3-9-1
Supports AUTOSAR19 Rule M3-9-1
Supports MISRA C 2004 Rule 8.3 - For each function parameter the type given in the declaration and deﬁnition shall be identical, and the return types shall also be identical.
Supports MISRA C 2012 Rule 8.3 - All declarations of an object or function shall use the same names and type qualiﬁers
Supports MISRA C:2023 Rule 8.3 - All declarations of an object or function shall use the same names and type qualiﬁers
Supports MISRA C:2025 Rule 8.3
Supports MISRA C++:2008 Rule 3-9-1 - The types used for an object, a function return type, or a function parameter shall be token-for-token identical in all declarations and re-declarations.
Supports MISRA C++:2023 Rule 6.9.1 - The same type aliases shall be used in all declarations of the same entity

9074
note
conversion between pointer to function type type and diﬀering type type
A conversion was seen between a pointer to function and a diﬀerent type. The conversion of a pointer to a function into or from a pointer to object, pointer to incomplete type, or pointer to void results in undeﬁned behavior and, consequently, at least one standards organization advises against such practice. This diagnostic is suppressed if the conversion is to void.
Supports CERT C DCL07-C - Include the appropriate type information in function declarators
Supports MISRA C 2012 Rule 11.1 - Conversions shall not be performed between a pointer to a function and any other type
Supports MISRA C:2023 Rule 11.1 - Conversions shall not be performed between a pointer to a function and any other type
Supports MISRA C:2025 Rule 11.1
Supports MISRA C++:2023 Rule 8.2.4 - Casts shall not be performed between a pointer to function and any other type

9075
note
external symbol symbol deﬁned without a prior declaration
If a declaration for an object is visible when that object is deﬁned, a compiler must verify that the declaration and deﬁnition are compatible. A lack of prior declaration prevents such checking.
Supports MISRA C 2012 Rule 8.4 - A compatible declaration shall be visible when an object or function with external linkage is deﬁned
Supports MISRA C:2023 Rule 8.4 - A compatible declaration shall be visible when an object or function with external linkage is deﬁned
Supports MISRA C:2025 Rule 8.4

9076
note
cast from type to type involves a pointer to an incomplete type other than void
A conversion between two distinct types involved a pointer to an incomplete type. The resulting pointer may be improperly aligned and the result of interpreting the target memory using a diﬀerent type may be a trap representation. Conversions to void and conversions to or from a pointer to void will not be reported.
Supports MISRA C 2012 Rule 11.2 - Conversions shall not be performed between a pointer to an incomplete type and any other type
Supports MISRA C:2023 Rule 11.2 - Conversions shall not be performed between a pointer to an incomplete type and any other type
Supports MISRA C:2025 Rule 11.2

9077
note
missing unconditional break from ﬁnal switch case
A case at the end of a switch had no unconditional break. Some coding guidelines require the use of a break for every switch case, including the last one, for maintenance reasons. Note that this message is issued even if the case contains an unconditional return statement.

Supports MISRA C 2012 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C 2012 Rule 16.3 - An unconditional break statement shall terminate every switch-clause
Supports MISRA C:2023 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C:2023 Rule 16.3 - An unconditional break statement shall terminate every switch-clause
Supports MISRA C:2025 Rule 16.1
Supports MISRA C:2025 Rule 16.3

9078
note
conversion between object pointer type type and integer type type
A conversion between an object pointer type and an integer/enum type was seen. Such conversions can result in undeﬁned behavior if the pointer value cannot be represented in the integer/enum type. This diagnostic is not given for null pointer constants.
Supports MISRA C 2012 Rule 11.4 - A conversion should not be performed between a pointer to object and an integer type
Supports MISRA C:2023 Rule 11.4 - A conversion should not be performed between a pointer to object and an integer type
Supports MISRA C:2025 Rule 11.4
Supports MISRA C++:2023 Rule 8.2.8 - An object pointer type shall not be cast to an integral type other than std::uintptr_t or std::intptr_t

9079
note
conversion from pointer to void to other pointer type (type)
Conversion of a pointer to void into a pointer to object may result in a pointer that is not correctly aligned, resulting in undeﬁned behavior.
Supports AUTOSAR17 Rule M5-2-8
Supports AUTOSAR19 Rule M5-2-8
Supports MISRA C 2012 Rule 11.5 - A conversion should not be performed from pointer to void into pointer to object
Supports MISRA C:2023 Rule 11.5 - A conversion should not be performed from pointer to void into pointer to object
Supports MISRA C:2025 Rule 11.5
Supports MISRA C++:2008 Rule 5-2-8 - An object with integer type or pointer to void type shall not be converted to an object with pointer type.

9080
note
integer null pointer constant is not the NULL macro
An integer null pointer constant other than the NULL macro was used. Using the NULL macro makes it clear a null pointer constant was intended. Record types containing pointer ﬁelds and arrays of pointers are exempt from this diagnostic if they are initialized using the single zero initializer.
Supports MISRA C 2012 Rule 11.9 - The macro NULL shall be the only permitted form of integer null pointer constant
Supports MISRA C:2023 Rule 11.9 - The macro NULL shall be the only permitted form of integer null pointer constant
Supports MISRA C:2025 Rule 11.9

9081
note
too few independent cases for switch
A switch was seen with fewer than two non-consecutive case labels. A switch with fewer than two such cases is redundant and may indicate a programming error. See also message 9181 .
Supports MISRA C 2012 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C 2012 Rule 16.6 - Every switch statement shall have at least two switch-clauses
Supports MISRA C:2023 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C:2023 Rule 16.6 - Every switch statement shall have at least two switch-clauses
Supports MISRA C:2025 Rule 16.1
Supports MISRA C:2025 Rule 16.6

9082
note
switch should begin or end with default
Placing the default label either ﬁrst or last makes locating it easier.
Supports MISRA C 2012 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C 2012 Rule 16.5 - A default label shall appear as either the ﬁrst or the last switch label of a switch statement
Supports MISRA C:2023 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C:2023 Rule 16.5 - A default label shall appear as either the ﬁrst or the last switch label of a switch statement
Supports MISRA C:2025 Rule 16.1
Supports MISRA C:2025 Rule 16.5

9083
note
undeﬁned macro name 'name' is reserved to the compiler
A #undef was seen applied to an identiﬁer given by name and that identiﬁer is reserved to the compiler by the ISO C/C++ standards.
Supports MISRA C 2004 Rule 20.1 - Reserved identiﬁers, macros and functions in the standard library, shall not be deﬁned, redeﬁned or undeﬁned.
Supports MISRA C 2012 Rule 21.1 - #deﬁne and #undef shall not be used on a reserved identiﬁer or reserved macro name
Supports MISRA C:2023 Rule 21.1 - #deﬁne and #undef shall not be used on a reserved identiﬁer or reserved macro name
Supports MISRA C:2025 Rule 20.15

9084
note
result of assignment operator used in string
An assignment expression was seen inside a larger expression. The use of assignment operators, simple or compound, in combination with other arithmetic operations can signiﬁcantly impair the readability of the code.
Supports AUTOSAR17 Rule M6-2-1
Supports AUTOSAR19 Rule M6-2-1
Supports MISRA C 2012 Rule 13.4 - The result of an assignment operator should not be used
Supports MISRA C:2023 Rule 13.4 - The result of an assignment operator should not be used
Supports MISRA C:2025 Rule 13.4
Supports MISRA C++:2008 Rule 6-2-1 - Assignment operators shall not be used in sub-expressions.
Supports MISRA C++:2023 Rule 8.18.2 - The result of an assignment operator should not be used

9085
note
statement or comment should appear in default case
A default label was seen without a comment or statement between it and either the corresponding break or, if default is the last case in the switch, the closing }. Adding a statement to take action or adding a comment to explain why no action is taken is a form of defensive programming.
Supports MISRA C 2012 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C 2012 Rule 16.4 - Every switch statement shall have a default label
Supports MISRA C:2023 Rule 16.1 - All switch statements shall be well-formed
Supports MISRA C:2023 Rule 16.4 - Every switch statement shall have a default label
Supports MISRA C:2025 Rule 16.1
Supports MISRA C:2025 Rule 16.4

9087
note
cast from pointer to object type (type) to pointer to diﬀerent object type (type)
A cast was seen between two pointer types that diﬀer with respect to what those types point to. Additionally, the type to which the expression was cast is not a pointer to char, whether signed or unsigned. At least one standards organization has cautioned against such a practice.
Supports MISRA C 2004 Rule 11.4 - A cast should not be performed between a pointer to object type and a diﬀerent pointer to object type.
Supports MISRA C 2012 Rule 11.3 - A cast shall not be performed between a pointer to object type and a pointer to a diﬀerent object type
Supports MISRA C:2023 Rule 11.3 - A cast shall not be performed between a pointer to object type and a pointer to a diﬀerent object type
Supports MISRA C:2025 Rule 11.3

9088
note
named signed single-bit bitﬁeld
A named bit-ﬁeld was declared with a signed data type and only one bit of width. According to the ISO C Standard, a single-bit signed bit-ﬁeld has one sign bit and no value bits and, consequently does not specify a meaningful value.
Supports AUTOSAR19 Rule M9-6-4
Supports CERT C INT16-C - Do not make assumptions about representation of signed integers
Supports MISRA C 2004 Rule 6.5 - Bit ﬁelds of type signed int shall be at least 2 bits long.
Supports MISRA C 2012 Rule 6.2 - Single-bit named bit ﬁelds shall not be of a signed type
Supports MISRA C:2023 Rule 6.2 - Single-bit named bit ﬁelds shall not be of a signed type
Supports MISRA C:2025 Rule 6.2
Supports MISRA C++:2008 Rule 9-6-4 - Named bit-ﬁelds with signed integer type shall have a length of more than one bit.
Supports MISRA C++:2023 Rule 12.2.3 - A named bit-ﬁeld with signed integer type shall not have a length of one bit

9090
note
switch case lacks unconditional break or throw
A switch case was seen that did not conclude with an unconditional break. Some authors advise against such absences on the grounds they are often errors.
Supports AUTOSAR17 Rule M6-4-5
Supports AUTOSAR19 Rule M6-4-5
Supports MISRA C 2004 Rule 15.2 - An unconditional break statement shall terminate every non-empty switch clause.
Supports MISRA C 2012 Rule 16.3 - An unconditional break statement shall terminate every switch-clause
Supports MISRA C:2023 Rule 16.3 - An unconditional break statement shall terminate every switch-clause
Supports MISRA C:2025 Rule 16.3
Supports MISRA C++:2008 Rule 6-4-5 - An unconditional throw or break statement shall terminate every non-empty switch-clause.

9091
note
casting from pointer type type to integer type type
A cast of a pointer to an integer type was seen. Since the size of the integer required when a pointer is converted to an integer is implementation deﬁned, some coding guidelines advise against such casts.
Supports AUTOSAR17 Rule M5-2-9
Supports AUTOSAR19 Rule M5-2-9
Supports MISRA C++:2008 Rule 5-2-9 - A cast should not convert a pointer type to an integral type.
Supports MISRA C++:2023 Rule 8.2.7 - A cast should not convert a pointer type to an integral type

9093
note
the name 'name' is reserved to the compiler
A symbol was declared with a name reserved to the compiler.
Supports AUTOSAR17 Rule A17-0-1
Supports AUTOSAR17 Rule M17-0-2
Supports AUTOSAR19 Rule A17-0-1
Supports AUTOSAR19 Rule M17-0-2
Supports CERT C DCL37-C - Do not declare or deﬁne a reserved identiﬁer
Supports MISRA C 2004 Rule 20.2 - The names of standard library macros, objects and functions shall not be reused.
Supports MISRA C 2012 Rule 21.2 - A reserved identiﬁer or macro name shall not be declared
Supports MISRA C:2023 Rule 21.2 - A reserved identiﬁer or macro name shall not be declared
Supports MISRA C:2025 Rule 5.10
Supports MISRA C++:2008 Rule 17-0-2 - The names of standard library macros and objects shall not be reused.

9094
note
return type of function symbol has type alias name diﬀerence with previous declaration (type vs type)
This message is similar to 9073 (which deals with parameter types) but applies to return types. In a declaration of a function, the return type speciﬁed, while technically identical, uses a diﬀerent type name than was used for a previous declaration. For example:

typedef int INT; 
int foo(void); 
INT foo(void) { 
   ... 
}

will yield this message.
Supports AUTOSAR17 Rule M3-9-1
Supports AUTOSAR19 Rule M3-9-1
Supports MISRA C 2004 Rule 8.3 - For each function parameter the type given in the declaration and deﬁnition shall be identical, and the return types shall also be identical.
Supports MISRA C 2012 Rule 8.3 - All declarations of an object or function shall use the same names and type qualiﬁers
Supports MISRA C:2023 Rule 8.3 - All declarations of an object or function shall use the same names and type qualiﬁers
Supports MISRA C:2025 Rule 8.3
Supports MISRA C++:2008 Rule 3-9-1 - The types used for an object, a function return type, or a function parameter shall be token-for-token identical in all declarations and re-declarations.
Supports MISRA C++:2023 Rule 6.9.1 - The same type aliases shall be used in all declarations of the same entity

9095
note
symbol symbol has same name as previously deﬁned macro
A symbol was deﬁned with the same name as a macro that was deﬁned earlier in the same translation unit. For example:

#define sum(x, y) ((x)+(y)) 
int sum = 0;

will produce:

note 9095: symbol 'sum' has same name as previously defined macro

A supplemental message (891 ) provides the location of the oﬀending macro deﬁnition. Note that the message is issued regardless of whether the macro deﬁnition is active at the point in which the symbol is declared. For example:

#define A 
#undef A 
int A = 0;

will elicit the same complaint for the declaration of A.
Supports MISRA C 2012 Rule 5.5 - Identiﬁers shall be distinct from macro names
Supports MISRA C:2023 Rule 5.5 - Identiﬁers shall be distinct from macro names
Supports MISRA C:2025 Rule 5.5

9096
note
symbol symbol has same name as subsequently deﬁned macro
This message is similar to 9095 but is issued for symbols deﬁned with the same name as a macro whose deﬁnition appears after the declaration of the symbol. For example:

int A; 
#define A 10

Unlike message 652 , this message will be issued even if the macro is deﬁned outside the scope of the symbol. For example:

void foo(int x) { } 
#define x 10

will not result in a 652 warning since the deﬁnition of the x macro is outside the scope of the function parameter but 9096 will still be issued.

A supplemental message (891 ) provides the location of the oﬀending macro deﬁnition.
Supports MISRA C 2012 Rule 5.5 - Identiﬁers shall be distinct from macro names
Supports MISRA C:2023 Rule 5.5 - Identiﬁers shall be distinct from macro names
Supports MISRA C:2025 Rule 5.5

9097
note
unparenthesized argument to sizeof operator
An unparenthesized expression was used as the argument to the sizeof operator. While legal, it can result in confusion when used within a larger expression, e.g.:

size = sizeof x + y;

was this meant to be sizeof(x) + y or sizeof(x + y)? Using parenthesis can eliminate such questions.
Supports MISRA C 2012 Rule 12.1 - The precedence of operators within expressions should be made explicit
Supports MISRA C:2023 Rule 12.1 - The precedence of operators within expressions should be made explicit
Supports MISRA C:2025 Rule 12.1
Supports MISRA C++:2023 Rule 8.0.1 - Parentheses should be used to make the meaning of an expression appropriately explicit

9098
note
pointer argument integer (of type type) to function symbol does not point to a pointer type or an essentially signed, unsigned, boolean, or enum type
The ﬁrst or second argument to memcmp (or a function with semantics copied from memcmp) was not either 1) a pointer to a pointer or 2) a pointer to a MISRA C 2012 essentially signed, unsigned, boolean, or enum type.
Supports MISRA C 2012 AMD1 Rule 21.16 - The pointer arguments to the Standard Library function memcmp shall point to either a pointer type, an essentially signed type, an essentially unsigned type, an essentially Boolean type or an essentially enum type
Supports MISRA C:2023 Rule 21.16 - The pointer arguments to the Standard Library function memcmp shall point to either a pointer type, an essentially signed type, an essentially unsigned type, an essentially Boolean type or an essentially enum type
Supports MISRA C:2025 Rule 21.16

9099
note
logical operator 'string' contains a pointer operand
This message reports the use of a pointer operand for logical operations (&&, ||, or !). For binary operators, the message emits if one or both operands are pointers. For example:

   void foo(int* p1, int* p2) { 
      if (p1 && p2) { 
          /* ... */ 
      } 
   }

will trigger the message.
Supports MISRA C 2012 Rule 10.1 - Operands shall not be of an inappropriate essential type
Supports MISRA C:2023 Rule 10.1 - Operands shall not be of an inappropriate essential type
Supports MISRA C:2025 Rule 11.11

9102
note
possible digraph sequence: 'string'
A possible digraph was seen. At least one set of coding guidelines advises against such due to the risk of failure to meet developer expectations.
Supports AUTOSAR17 Rule A2-6-1
Supports AUTOSAR19 Rule A2-5-2
Supports MISRA C++:2008 Rule 2-5-1 - Digraphs should not be used.

9103
note
identiﬁer 'name' with static storage is reused by symbol
An identiﬁer reuses the name of a non-member object or function with static storage duration. A local static variable is not considered a static identiﬁer for the purposes of the message. For example:

int x = 0; 
struct S { int x; };  // note 9103

Some coding guidelines advise against such practice due to the potential for programmer confusion.

Project-wide unique identiﬁers are also enforced by messages 9275 , 9276 , 9277 , 9278 , and 9279 . A more strict enforcement of unique identiﬁers can be applied using the +misra_interpret(any, strict identiﬁer uniqueness) option.
Supports AUTOSAR17 Rule A2-11-5
Supports AUTOSAR19 Rule A2-10-5
Supports MISRA C 2004 Rule 5.5 - No object or function identiﬁer with static storage duration should be reused.
Supports MISRA C++:2008 Rule 2-10-5 - The identiﬁer name of a non-member object or function with static storage duration should not be reused.

9104
note
octal escape sequence used
Octal escape sequences can be problematic because the inadvertent introduction of a decimal digit (i.e. 8 or 9) ends the octal escape and introduces another character. This diagnostic is not given for \0.
Supports AUTOSAR17 Rule M2-13-2
Supports AUTOSAR19 Rule M2-13-2
Supports MISRA C 2004 Rule 4.1 - Only those escape sequences that are deﬁned in the ISO C standard shall be used.
Supports MISRA C 2004 Rule 7.1 - Octal constants (other than zero) and octal escape sequences shall not be used.
Supports MISRA C++:2008 Rule 2-13-2 - Octal constants (other than zero) and octal escape sequences (other than "\0") shall not be used.

9105
note
unsigned octal and hexadecimal literals require a 'U' suﬃx
The inclusion of such a suﬃx makes clear the value has unsigned type.
Supports AUTOSAR17 Rule M2-13-3
Supports AUTOSAR19 Rule M2-13-3
Supports MISRA C++:2008 Rule 2-13-3 - A "U " suﬃx shall be applied to all octal or hexadecimal integer literals of unsigned type.

9106
note
lower case literal suﬃx, 'string'
Using upper case literal suﬃxes removes the potential for ambiguity with respect to literal values.

Supports AUTOSAR17 Rule M2-13-4
Supports AUTOSAR19 Rule M2-13-4
Supports MISRA C++:2008 Rule 2-13-4 - Literal suﬃxes shall be upper case.

9107
note
header cannot be included in more than one translation unit because of the deﬁnition of symbol symbol
One set of guidelines advises the use of headers in such a way as to avoid the deﬁnition of objects or functions that occupy storage.
Supports AUTOSAR17 Rule A3-1-1
Supports AUTOSAR19 Rule A3-1-1
Supports MISRA C 2004 Rule 8.5 - There shall be no deﬁnitions of objects or functions in a header ﬁle.
Supports MISRA C++:2008 Rule 3-1-1 - It shall be possible to include any header ﬁle in multiple translation units without violating the One Deﬁnition Rule.
Supports MISRA C++:2023 Rule 6.2.4 - A header ﬁle shall not contain deﬁnitions of functions or objects that are non-inline and have external linkage

9108
note
function symbol declared at block scope
A function was declared within the body of another function. The inner declaration will be associated with a deﬁnition in the scope enclosing the outer function for linking purposes but the name will be meaningful only within the body of the enclosing function unless re-declared elsewhere.

If a block scope declaration occurs within a namespace in C++ then message 1798 will also be issued to highlight the heightened danger of confusion.
Supports AUTOSAR17 Rule M3-1-2
Supports AUTOSAR19 Rule M3-1-2
Supports MISRA C 2004 Rule 8.6 - Functions shall be declared at ﬁle scope.
Supports MISRA C++:2008 Rule 3-1-2 - Functions shall not be declared at block scope.
Supports MISRA C++:2023 Rule 6.0.1 - Block scope declarations shall not be visually ambiguous

9110
note
bit representation of a ﬂoating point type used (conversion from type to type)
The under lying bit representation of ﬂoating point values can diﬀer from compiler to compiler, making reliance upon such representation non-portable.
Supports AUTOSAR17 Rule M3-9-3
Supports AUTOSAR19 Rule M3-9-3
Supports MISRA C 2004 Rule 12.12 - The underlying bit representations of ﬂoating-point values shall not be used.
Supports MISRA C++:2008 Rule 3-9-3 - The underlying bit representations of ﬂoating-point values shall not be used.

9111
note
boolean expression used with non-permitted operator 'string'
The use of expressions of bool with certain operators, such as the bitwise operators, is not likely to be either meaningful or intended.
Supports AUTOSAR17 Rule M4-5-1
Supports AUTOSAR19 Rule M4-5-1
Supports MISRA C++:2008 Rule 4-5-1 - Expressions with type bool shall not be used as operands to built-in operators other than the assignment operator =, the logical operators &&, ||, !, the equality operators == and !=, the unary & operator, and the conditional operator.
Supports MISRA C++:2023 Rule 7.0.1 - There shall be no conversion from type bool

9112
note
plain character expression used with non-permitted operator 'string'
With the exception of the sequence of character values representing 0 thru 9, the exact value of any other particular character is not guaranteed and reliance upon such an order is non-portable.
Supports AUTOSAR17 Rule M4-5-3
Supports AUTOSAR19 Rule M4-5-3
Supports CERT C INT07-C - Use only explicitly signed or unsigned char type for numeric values
Supports CWE-682 - Incorrect Calculation
Supports MISRA C++:2008 Rule 4-5-3 - Expressions with type (plain) char and wchar_t shall not be used as operands to built-in operators other than the assignment operator =, the equality operators == and !=, and the unary & operator.

9113
note
dependence placed on C++ operator precedence
The use of parentheses instead of relying upon operator precedence can help make the code easier to understand.
Supports AUTOSAR17 Rule M5-0-2
Supports AUTOSAR19 Rule M5-0-2
Supports CWE-783 - Operator Precedence Logic Error
Supports MISRA C++:2008 Rule 5-0-2 - Limited dependence should be placed on C++ operator precedence rules in expressions.

9114
note
implicit conversion of underlying type of integer cvalue expression from underlying-type to underlying type
A prominent coding standard has deﬁned the notion of a cvalue expression and, to help ensure operations in a given expression are performed within a particular fashion, the guidelines caution against such a value undergoing implicit conversions.
Supports AUTOSAR17 Rule M5-0-3
Supports AUTOSAR19 Rule M5-0-3
Supports MISRA C++:2008 Rule 5-0-3 - A cvalue expression shall not be implicitly converted to a diﬀerent underlying type.

9115
note
implicit conversion from integer to ﬂoating point type
Such conversions between these two types of values can result in inexact representation.
Supports AUTOSAR17 Rule M5-0-5
Supports AUTOSAR19 Rule M5-0-5
Supports MISRA C++:2008 Rule 5-0-5 - There shall be no implicit ﬂoating-integral conversions.

9116
note
implicit conversion of underlying type of ﬂoating point cvalue expression from underlying-type to underlying type
A prominent coding standard has deﬁned the notion of a cvalue expression and, to help ensure operations in a given expression are performed within a particular fashion, the guidelines caution against such a value undergoing implicit conversions.
Supports AUTOSAR17 Rule M5-0-3
Supports AUTOSAR19 Rule M5-0-3
Supports MISRA C++:2008 Rule 5-0-3 - A cvalue expression shall not be implicitly converted to a diﬀerent underlying type.

9117
note
implicit conversion from underlying-type to underlying-type changes signedness of underlying type
Some such conversions can lead to implementation deﬁned behavior. Reliance upon such behavior is, therefore, not portable.
Supports AUTOSAR17 Rule M5-0-4
Supports AUTOSAR19 Rule M5-0-4
Supports MISRA C++:2008 Rule 5-0-4 - An implicit integral conversion shall not change the signedness of the underlying type.

9118
note
implicit conversion from ﬂoating point to integer type
Such conversions between these two types of values can result in undeﬁned behavior.
Supports AUTOSAR17 Rule M5-0-5
Supports AUTOSAR19 Rule M5-0-5
Supports CERT C FLP34-C - Ensure that ﬂoating-point conversions are within range of the new type
Supports CWE-197 - Numeric Truncation Error
Supports CWE-681 - Incorrect Conversion between Numeric Types
Supports MISRA C++:2008 Rule 5-0-5 - There shall be no implicit ﬂoating-integral conversions.

9119
note
implicit conversion of integer to smaller underlying type (type to type)
A conversion was performed from an integer to a type that has a smaller MISRA C++ underlying type.
Supports AUTOSAR17 Rule M5-0-6
Supports AUTOSAR19 Rule M5-0-6
Supports MISRA C++:2008 Rule 5-0-6 - An implicit integral or ﬂoating-point conversion shall not reduce the size of the underlying type.

9120
note
implicit conversion of ﬂoating point to smaller underlying type (type to type)
A conversion was performed from a ﬂoating point type to a type that has a smaller MISRA C++ underlying type.
Supports AUTOSAR17 Rule M5-0-6
Supports AUTOSAR19 Rule M5-0-6
Supports CERT C FLP03-C - Detect and handle ﬂoating-point errors
Supports CWE-369 - Divide By Zero
Supports MISRA C++:2008 Rule 5-0-6 - An implicit integral or ﬂoating-point conversion shall not reduce the size of the underlying type.

9121
note
cast of cvalue expression from integer to ﬂoating point type

A cast was used to convert a MISRA C++ cvalue expression from an integral to ﬂoating point type.
Supports AUTOSAR17 Rule M5-0-7
Supports AUTOSAR19 Rule M5-0-7
Supports MISRA C++:2008 Rule 5-0-7 - There shall be no explicit ﬂoating-integral conversions of a cvalue expression.

9122
note
cast of cvalue expression from ﬂoating point to integer type
A cast was used to convert a MISRA C++ cvalue expression from a ﬂoating point to integral type.
Supports AUTOSAR17 Rule M5-0-7
Supports AUTOSAR19 Rule M5-0-7
Supports MISRA C++:2008 Rule 5-0-7 - There shall be no explicit ﬂoating-integral conversions of a cvalue expression.

9123
note
cast of integer cvalue expression to larger type
A cast was used to convert a MISRA C++ cvalue expression of integral type to a type with a larger underlying type.
Supports AUTOSAR17 Rule M5-0-8
Supports AUTOSAR19 Rule M5-0-8
Supports MISRA C++:2008 Rule 5-0-8 - An explicit integral or ﬂoating-point conversion shall not increase the size of the underlying type of a cvalue expression.

9124
note
cast of ﬂoating point cvalue expression to larger type
A cast was used to convert a MISRA C++ cvalue expression of ﬂoating point type to a type with a larger underlying type.
Supports AUTOSAR17 Rule M5-0-8
Supports AUTOSAR19 Rule M5-0-8
Supports MISRA C++:2008 Rule 5-0-8 - An explicit integral or ﬂoating-point conversion shall not increase the size of the underlying type of a cvalue expression.

9125
note
cast of integer cvalue expression changes signedness
A cast was used to convert a MISRA C++ cvalue expression of integral type to an underlying type with a diﬀerent signedness.
Supports AUTOSAR17 Rule M5-0-9
Supports AUTOSAR19 Rule M5-0-9
Supports MISRA C++:2008 Rule 5-0-9 - An explicit integral conversion shall not change the signedness of the underlying type of a cvalue expression.

9126
note
the result of the operator operator applied to an object with an underlying type of underlying-type must be cast to type in this context
The ~ or << operator was applied to an operand with a MISRA C++ underlying type of unsigned char or unsigned short but the result was not cast to the appropriate underlying type.
Supports AUTOSAR17 Rule M5-0-10
Supports AUTOSAR19 Rule M5-0-10
Supports MISRA C++:2008 Rule 5-0-10 - If the bitwise operators ~ and « are applied to an operand with an underlying type of unsigned char or unsigned short, the result shall be immediately cast to the underlying type of the operand.

9128
note
plain character data mixed with non-plain-character data
A prominent standard urges, since whether plain char is signed or unsigned is implementation deﬁned, the char type not be mixed with other types.

Supports AUTOSAR17 Rule M5-0-11
Supports AUTOSAR19 Rule M5-0-11
Supports MISRA C 2004 Rule 6.1 - The plain char type shall be used only for storage and use of character values.
Supports MISRA C 2004 Rule 6.2 - signed and unsigned char type shall be used only for the storage and use of numeric values.
Supports MISRA C++:2008 Rule 5-0-11 - The plain char type shall only be used for the storage and use of character values.

9130
note
bitwise operator 'operator' applied to signed underlying type
The speciﬁed bitwise operator was applied to an operand with a signed MISRA C++ underlying type.
Supports AUTOSAR17 Rule M5-0-21
Supports AUTOSAR19 Rule M5-0-21
Supports MISRA C++:2008 Rule 5-0-21 - Bitwise operators shall only be applied to operands of unsigned underlying type.

9131
note
left/right side of logical operator 'operator' is not a postﬁx expression
Using only postﬁx-expressions with logical operators helps to improve readability of the code. Note this message is not given if the expression consists of either a sequence of only logical && or a sequence of only logical ||.
Supports AUTOSAR17 Rule M5-2-1
Supports MISRA C++:2008 Rule 5-2-1 - Each operand of a logical && or || shall be a postﬁx-expression.

9132
note
array type passed to function expecting a pointer
Array-to-pointer decay results in a loss of array bound information. A function depending upon an array to have a certain length, if that array decays to a pointer, can result in out-of-bounds operations, depending upon whether or not the bound of the original array matches with expectations.
Supports AUTOSAR17 Rule M5-2-12
Supports AUTOSAR19 Rule M5-2-12
Supports MISRA C++:2008 Rule 5-2-12 - An identiﬁer with array type passed as a function argument shall not decay to a pointer.
Supports MISRA C++:2023 Rule 7.11.2 - An array passed as a function argument shall not decay to a pointer

9133
note
boolean expression required for operator 'string'
The use of non-bool operands with !, &&, or || is unlikely to be meaningful or intended. A more likely scenario is the programmer meant to use such an operand with one of the bitwise operators.
Supports AUTOSAR17 Rule M5-3-1
Supports AUTOSAR19 Rule M5-3-1
Supports MISRA C++:2008 Rule 5-3-1 - Each operand of the ! operator, the logical && or the logical || operators shall have type bool.

9134
note
unary minus applied to operand with unsigned underlying type
A unary minus was applied to an expression with an unsigned MISRA C++ underlying type.
Supports AUTOSAR17 Rule M5-3-2
Supports AUTOSAR19 Rule M5-3-2
Supports MISRA C++:2008 Rule 5-3-2 - The unary minus operator shall not be applied to an expression whose underlying type is unsigned.
Supports MISRA C++:2023 Rule 8.3.1 - The built-in unary - operator should not be applied to an expression of unsigned type

9135
note
unary operator & overloaded
The unary operator & was overloaded.
Supports AUTOSAR17 Rule M5-3-3
Supports AUTOSAR19 Rule M5-3-3
Supports MISRA C++:2008 Rule 5-3-3 - The unary & operator shall not be overloaded.
Supports MISRA C++:2023 Rule 16.5.2 - The address-of operator shall not be overloaded

9136
note
the shift value is at least the precision of the MISRA C++ underlying type of the left hand side
The value speciﬁed for the right hand side of a shift operator was out of bounds for the MISRA C++ underlying type on the left hand side of the operator.
Supports AUTOSAR17 Rule M5-8-1
Supports AUTOSAR19 Rule M5-8-1
Supports MISRA C++:2008 Rule 5-8-1 - The right hand operand of a shift operator shall lie between zero and one less than the width in bits of the underlying type of the left hand operand.

9137
note
testing ﬂoating point values for equality
This message is deprecated and will be removed in a future version. Use messages 777 and/or 9252 instead.
A ﬂoating point value was tested, directly or indirectly, for (in)equality with another value.

9138
note
null statement not on line by itself
A null statement was encountered that, before preprocessing, did not appear on a line by itself. Comments following the null statement are allowed as long as there is whitespace separating the null statement from the comment.
Supports AUTOSAR17 Rule M6-2-3
Supports AUTOSAR19 Rule M6-2-3
Supports MISRA C 2004 Rule 14.3 - Before preprocessing, a null statement shall only occur on a line by itself; it may be followed by a comment provided that the ﬁrst character following the null statement is a white-space character.
Supports MISRA C++:2008 Rule 6-2-3 - Before preprocessing, a null statement shall only occur on a line by itself; it may be followed by a comment, provided that the ﬁrst character following the null statement is a white-space character.

9139
note
case label follows default in switch statement
A case label was encountered following the default label of a switch statement.
Supports AUTOSAR17 Rule M6-4-6
Supports AUTOSAR19 Rule M6-4-6
Supports MISRA C 2004 Rule 15.3 - The ﬁnal clause of a switch statement shall be the default clause.
Supports MISRA C++:2008 Rule 6-4-6 - The ﬁnal clause of a switch statement shall be the default-clause.

9140
note
continue statement detected outside of well-formed for loop
A continue statement appears outside of a well-formed for loop.

for (int x = 0; x == 10; x += 2) { 
   x += 2; 
   if (x % 6) { continue; }  // note 9140 
}

For the purpose of this message, the MISRA C++ 2008 deﬁnition of a well-formed for loop is used. A well-formed for loop satisﬁes MISRA C++ 2008 Rule 6-5-1 through Rule 6-5-6. PC-lint Plus uses messages 850 , 2840 , 9009 , 9191 , 9192 , 9193 , 9194 , 9195 , and 9196 to enforce these rules. Suppressing these other messages will not make PC-lint Plus consider the for loop to be well-formed, and separate suppression of this message may be necessary.
Supports AUTOSAR17 Rule M6-6-3
Supports AUTOSAR19 Rule M6-6-3
Supports MISRA C++:2008 Rule 6-6-3 - The continue statement shall only be used within a well-formed for loop.

9141
note
global declaration of symbol symbol
The speciﬁed symbol was declared in the global namespace. The main function does not receive this message.

int global = 0;  // note 9141 
int main() {}

See message 9255 for inline namespaces declared in the global namespace.
Supports AUTOSAR17 Rule M7-3-1
Supports AUTOSAR19 Rule M7-3-1
Supports MISRA C++:2008 Rule 7-3-1 - The global namespace shall only contain main, namespace declarations and extern "C" declarations.
Supports MISRA C++:2023 Rule 6.0.3 - The only declarations in the global namespace should be main, namespace declarations and extern "C" declarations

9142
note
function main declared outside the global namespace
A function with the name ’main’ was declared that was not the global main function.
Supports AUTOSAR17 Rule M7-3-2
Supports AUTOSAR19 Rule M7-3-2
Supports MISRA C++:2008 Rule 7-3-2 - The identiﬁer main shall not be used for a function other than the global function main.
Supports MISRA C++:2023 Rule 6.0.4 - The identiﬁer main shall not be used for a function other than the global function main

9144
note
using directive used: 'string'
A using directive was encountered.
Supports AUTOSAR17 Rule M7-3-4
Supports AUTOSAR19 Rule M7-3-4
Supports MISRA C++:2008 Rule 7-3-4 - using-directives shall not be used.

9145
note
using declaration/directive in header 'ﬁle'
A using directive or using declaration was encountered in a header ﬁle. This message is not issued for using declarations in class or function scope.
Supports AUTOSAR17 Rule M7-3-6
Supports AUTOSAR19 Rule M7-3-6
Supports MISRA C++:2008 Rule 7-3-6 - using-directives and using-declarations (excluding class scope or function scope using-declarations) shall not be used in header ﬁles.

9146
note
multiple declarators in a declaration
A declaration was encountered that contains multiple declarators. For example:

int i, j;

will elicit this message.
Supports AUTOSAR17 Rule A7-1-7
Supports AUTOSAR17 Rule M8-0-1
Supports AUTOSAR19 Rule A7-1-7
Supports AUTOSAR19 Rule M8-0-1
Supports CERT C DCL04-C - Do not declare more than one variable per declaration
Supports MISRA C++:2008 Rule 8-0-1 - An init-declarator-list or a member-declarator-list shall consist of a single init-declarator or member-declarator respectively.
Supports MISRA C++:2023 Rule 10.0.1 - A declaration should not declare more than one variable or member variable

9147
note
implicit function-to-pointer decay
The unadorned name of a function was encountered that was not part of a function call.
Supports AUTOSAR17 Rule M8-4-4
Supports AUTOSAR19 Rule M8-4-4
Supports MISRA C 2004 Rule 16.9 - A function identiﬁer shall only be used with either a preceding &, or with a parenthesised parameter list, which may be empty.
Supports MISRA C 2012 AMD3 Rule 17.12 - A function identiﬁer should only be used with either a preceding &, or with a parenthesized parameter list
Supports MISRA C:2023 Rule 17.12 - A function identiﬁer should only be used with either a preceding &, or with a parenthesized parameter list
Supports MISRA C:2025 Rule 17.12
Supports MISRA C++:2008 Rule 8-4-4 - A function identiﬁer shall either be used to call the function or it shall be preceded by &.
Supports MISRA C++:2023 Rule 7.11.3 - A conversion from function type to pointer-to-function type shall only occur in appropriate contexts

9148
note
'=' should initialize either all enum members or only the ﬁrst for enumerator symbol
Unintentional duplication of enumerator values can occur when an enumeration consists of members with explicit and implicit values.
Supports AUTOSAR17 Rule A7-2-4
Supports AUTOSAR19 Rule A7-2-4
Supports CERT C INT09-C - Ensure enumeration constants map to unique values
Supports MISRA C 2004 Rule 9.3 - In an enumerator list, the "=" construct shall not be used to explicitly initialise members other than the ﬁrst, unless all items are explicitly initialised.
Supports MISRA C++:2008 Rule 8-5-3 - In an enumerator list, the = construct shall not be used to explicitly initialize members other than the ﬁrst, unless all items are explicitly initialized.

9149
note
bit ﬁeld must be explicitly signed integer, unsigned integer, or bool
When using ’int’ or ’wchar_t’ as the bit-ﬁeld type, it is implementation deﬁned whether or not the type used is a signed type. Explicitly specifying ’signed’ or ’unsigned’ makes it clear what type will be used as the underlying type.
Supports MISRA C 2012 Rule 6.1 - Bit-ﬁelds shall only be declared with an appropriate type
Supports MISRA C:2023 Rule 6.1 - Bit-ﬁelds shall only be declared with an appropriate type
Supports MISRA C:2025 Rule 6.1
Supports MISRA C++:2008 Rule 9-6-2 - Bit-ﬁelds shall be either bool type or an explicitly unsigned or signed integral type.
Supports MISRA C++:2008 Rule 9-6-3 - Bit-ﬁelds shall not have enum type.

9150
note
non-private data member symbol within a non-POD structure
A member of a non-POD structure was declared public or protected.
Supports AUTOSAR17 Rule M11-0-1
Supports AUTOSAR19 Rule M11-0-1
Supports MISRA C++:2008 Rule 11-0-1 - Member data in non-POD class types shall be private.

9151
note
abstract class symbol declares public copy assignment operator symbol
A public copy assignment operator was declared in an abstract class.

See message 1957 for copy/move constructors/assignment operators not declared protected nor deﬁned =delete in a base class.
Supports MISRA C++:2008 Rule 12-8-2 - The copy assignment operator shall be declared protected or private in an abstract class.

9153
note
viable set contains both function symbol and template symbol
In a context where a name resolves either to a non-template function or to a specialization of a function template (typically a call), the set of viable candidates included both.
Supports AUTOSAR17 Rule A14-8-1
Supports MISRA C++:2008 Rule 14-8-2 - The viable function set for a function call should either contain no function specializations, or only contain function specializations.

9154
note
throwing a pointer
A pointer type was passed to a throw expression. It may not be clear who is responsible for cleaning up the pointed to object.
Supports AUTOSAR17 Rule A15-1-2
Supports AUTOSAR19 Rule A15-1-2
Supports MISRA C++:2008 Rule 15-0-2 - An exception object should not have pointer type.
Supports MISRA C++:2023 Rule 18.1.1 - An exception object shall not have pointer type

9155
note
detail comment may contain commented-out code
A block, line, or C++ line block comment that appears to be commented-out code was encountered. Block comments are C style comments beginning with /*. Line comments are C++ style comments beginning with //. Consecutive C++ style line comments are treated as blocks. This is referred to as a "C++ line block comment". For example:

int a = 1;        // Okay 
int b = 1;        // Okay 
//int c = a + b;   // note 9155, line comment 
/*int d = c + b;*/  // note 9155, block comment 
//int e = d + c;   // note 9155, C++ line block comment 
//int f = e + d;

Commented-out code often creates maintainability issues, as it tends to quickly become out of date. Also, if C style comment markers are used, any comments nested within the block may create unexpected outcomes.

The message does not apply to documentation comments. Documentation comments are those that begin with /**, /*!, ///, or //!.
Supports AUTOSAR17 Rule A2-8-2
Supports AUTOSAR19 Rule A2-7-2
Supports MISRA C 2012 Dir 4.4 - Sections of code should not be "commented out"
Supports MISRA C:2023 Dir 4.4 - Sections of code should not be "commented out"
Supports MISRA C:2025 Dir 4.4
Supports MISRA C++:2023 Dir 5.7.2 - Sections of code should not be commented out

9156
note
rethrow outside of catch block will call std::terminate if no exception is being handled
An empty throw expression was encountered outside of a try-catch block. An empty throw re-throws the currently handled exception. If there is no such exception std::terminate() will be called. This is likely to be unintended.
Supports AUTOSAR17 Rule M15-1-3
Supports AUTOSAR17 Rule A15-5-2
Supports AUTOSAR17 Rule A15-5-3
Supports AUTOSAR19 Rule M15-1-3
Supports AUTOSAR19 Rule A15-5-2
Supports AUTOSAR19 Rule A15-5-3
Supports MISRA C++:2008 Rule 15-1-3 - An empty throw (throw;) shall only be used in the compound-statement of a catch handler.
Supports MISRA C++:2023 Rule 18.1.2 - An empty throw shall only occur within the compound-statement of a catch handler

9158
note
#deﬁne used within string symbol for macro 'name'
A macro was deﬁned inside the braced region of the entity described by string (such as function or class). Such usage could imply the belief that the scope of the macro deﬁnition is limited to the braced region, which is not the case.

Supports AUTOSAR17 Rule M16-0-2
Supports AUTOSAR19 Rule M16-0-2
Supports MISRA C 2004 Rule 19.5 - Macros shall not be #deﬁne’d or #undef’d within a block.
Supports MISRA C++:2008 Rule 16-0-2 - Macros shall only be #deﬁne’d or #undef’d in the global namespace.

9159
note
#undef used within string symbol for macro 'name'
A macro was undeﬁned inside the braced region of the entity described by string (such as function or class). Such usage could imply the belief that the scope of the directive is limited to the braced region, which is not the case.
Supports AUTOSAR17 Rule M16-0-2
Supports AUTOSAR19 Rule M16-0-2
Supports MISRA C 2004 Rule 19.5 - Macros shall not be #deﬁne’d or #undef’d within a block.
Supports MISRA C++:2008 Rule 16-0-2 - Macros shall only be #deﬁne’d or #undef’d in the global namespace.

9160
note
unknown preprocessor directive 'string' in conditionally excluded region
Within a conditionally excluded region, a line that started with a # was seen but was not part of a valid preprocessing directive. Error 16 is produced if an unknown preprocessor directive appears in a non-excluded region.
Supports AUTOSAR17 Rule M16-0-8
Supports AUTOSAR19 Rule M16-0-8
Supports MISRA C 2004 Rule 19.16 - Preprocessing directives shall be syntactically meaningful even when excluded by the preprocessor.
Supports MISRA C 2012 Rule 20.13 - A line whose ﬁrst token is # shall be a valid preprocessing directive
Supports MISRA C:2023 Rule 20.13 - A line whose ﬁrst token is # shall be a valid preprocessing directive
Supports MISRA C:2025 Rule 20.13
Supports MISRA C++:2008 Rule 16-0-8 - If the # token appears as the ﬁrst token on a line, then it shall be immediately followed by a preprocessing token.
Supports MISRA C++:2023 Rule 19.0.1 - A line whose ﬁrst token is # shall be a valid preprocessing directive

9161
note
operand to typeid operator has polymorphic type type
The typeid operator was supplied with an expression argument having polymorphic type. For example:

#include <typeinfo> 
 
struct Poly { 
   virtual void foo(); 
}; 
 
void test(Poly p) { 
   typeid(p);     // Note 9161 
   typeid(&p);    // Okay, pointer types are not polymorphic 
   typeid(Poly);  // Okay, type argument, not an expression 
}

Polymorphic expressions are sometimes evaluated by the typeid operator while other expressions are not. Evaluation of a polymorphic expression by the typeid operator may result in an exception being thrown. Using polymorphic expressions with typeid may warrant additional precautions that are not necessary with expressions of other types. The form of the typeid operator which receives a type argument cannot evaluate its argument and therefore will not be considered for this message.
Supports MISRA C++:2023 Rule 8.2.9 - The operand to typeid shall not be an expression of polymorphic class type

9162
note
use of 'string' at global scope
Either a static_assert() or a using-declaration was seen at global scope, as indicated by the string.
Supports AUTOSAR17 Rule M7-3-1
Supports AUTOSAR19 Rule M7-3-1
Supports MISRA C++:2008 Rule 7-3-1 - The global namespace shall only contain main, namespace declarations and extern "C" declarations.

9164
note
reinterpret_cast used to convert from type to type
A reinterpret_cast was encountered. For example:

void foo() { 
   auto ptr = reinterpret_cast<void *>(0xEF10);  // Note 9164 
}

There are several situations in which a conversion performed via reinterpret_cast is legal but use of the converted result may invoke undeﬁned behavior. Suppression options such as -etype /+etype /-equery /+equery may be used to enable this message for speciﬁc types of conversions. See also message 1423 which warns about uses of reinterpret_cast which always result in undeﬁned behavior.
Supports MISRA C++:2023 Rule 8.2.5 - reinterpret_cast shall not be used

9165
note
function symbol deﬁned with a variable number of arguments
The named function is deﬁned to take a variable number of arguments. At least one author advises against such a practice because doing so avoids the type checking provided by the compiler.
Supports AUTOSAR17 Rule A8-4-1
Supports AUTOSAR19 Rule A8-4-1
Supports MISRA C 2004 Rule 16.1 - Functions shall not be deﬁned with variable numbers of arguments.
Supports MISRA C++:2008 Rule 8-4-1 - Functions shall not be deﬁned using the ellipsis notation.

9167
note
macro 'name' deﬁned in string symbol not undeﬁned in same string
A macro was deﬁned inside of a declaration of a function, class/struct/union, namespace, or enumeration and was not undeﬁned within the braced region of that declaration. The macro will persist beyond the end of the declaration, which may not be intended. For example:

void foo() { 
#define A ... 
 
}

will result in the message:

macro ’A’ defined in function ’foo’ not undefined in same function

9168
note
variable symbol has type alias name diﬀerence with previous declaration (type vs type)
A variable is declared in two places with types that, while technically identical, have diﬀerent alias names. For example:

typedef int INT; 
extern int var; 
INT var;          // note 9168

Supports AUTOSAR17 Rule M3-9-1
Supports AUTOSAR19 Rule M3-9-1
Supports MISRA C++:2008 Rule 3-9-1 - The types used for an object, a function return type, or a function parameter shall be token-for-token identical in all declarations and re-declarations.
Supports MISRA C++:2023 Rule 6.9.1 - The same type aliases shall be used in all declarations of the same entity

9169
note
constructor symbol can be used for implicit conversions from fundamental type type
A constructor was found that could be used for implicit conversions from a fundamental type. This message is similar to 1931 but only reports instances where the implicit conversion is from a fundamental type (e.g. integer and ﬂoating point types but not pointers, references, arrays, classes, etc.). Like message 1931, if the constructor is declared with the keyword explicit, this message will not be emitted. This message is also not be emitted for variadic constructors.
Supports AUTOSAR17 Rule A12-1-4
Supports AUTOSAR19 Rule A12-1-4
Supports MISRA C++:2008 Rule 12-1-3 - All constructors that are callable with a single argument of fundamental type shall be declared explicit.

9170
note
pure function symbol overrides non-pure function symbol
The speciﬁed function is declared as pure but overrides a non-pure function in a base class. Was this a mistake?
Supports AUTOSAR17 Rule M10-3-3
Supports AUTOSAR19 Rule M10-3-3
Supports MISRA C++:2008 Rule 10-3-3 - A virtual function shall only be overridden by a pure virtual function if it is itself declared as pure virtual.

9171
note
downcast of polymorphic type type to type type
A cast was used to convert a pointer to a polymorphic type (a class that contains or inherits one or more virtual functions) to a pointer to a derived class.
Supports AUTOSAR17 Rule M5-2-3
Supports AUTOSAR19 Rule M5-2-3
Supports MISRA C++:2008 Rule 5-2-3 - Casts from a base class to a derived class should not be performed on polymorphic types.

9172
note
bitwise operator 'operator' used with non-constant operands of diﬀering underlying types (underlying-type and underlying-type)
A bitwise operator was used whose operands did not have the same MISRA C++ underlying type. This message is not produced if either operand is an integer constant expression.
Supports AUTOSAR17 Rule M5-0-20
Supports AUTOSAR19 Rule M5-0-20
Supports MISRA C++:2008 Rule 5-0-20 - Non-constant operands to a binary bitwise operator shall have the same underlying type.

9173
note
use of non-placement allocation function symbol
The use of new or delete was encountered that will allocate or deallocate dynamic memory. Placement new is not reported as it does not allocate memory.
Supports MISRA C++:2008 Rule 18-4-1 - Dynamic heap memory allocation shall not be used.
Supports MISRA C++:2023 Rule 21.6.2 - Dynamic memory shall be managed automatically

9174
note
type is a virtual base class of symbol
A class derivation was marked as virtual; some coding standards prohibit virtual inheritance due to the potential complexities involved.
Supports AUTOSAR17 Rule M10-1-1
Supports AUTOSAR19 Rule M10-1-1
Supports MISRA C++:2008 Rule 10-1-1 - Classes should not be derived from virtual bases.
Supports MISRA C++:2023 Rule 13.1.1 - Classes should not be inherited virtually

9175
note
function symbol has void return type and no external side-eﬀects
The speciﬁed function does not appear to have any external side-eﬀects and does not return any information so what is the purpose of calling the function?
Supports AUTOSAR17 Rule M0-1-8
Supports AUTOSAR19 Rule M0-1-8
Supports MISRA C++:2008 Rule 0-1-8 - All functions with void return type shall have external side eﬀect(s).

9176
note
pointer type type converted to unrelated pointer type type
A pointer was converted (implicitly or explicitly) to a diﬀerent pointer type and the source pointee type was not a class or structure derived from the destination pointee type.
Supports MISRA C++:2008 Rule 5-2-7 - An object with pointer type shall not be converted to an unrelated pointer type, either directly or indirectly.

9177
note
condition of 'string' statement has non-Boolean type type
The controlling expression of a do, for, if, or while statement had a non-Boolean type before applying the contextual Boolean conversion that occurs for the control statement. For example:

void foo(int value) { 
   if (value) { ... }        // Note 9177 
   if ((bool)value) { ... }   // OK 
   if (value != 0) { ... }    // OK 
}

As indicated in the above example, a cast to bool can be used to make the intention explicit and suppress this message. 9177 is not issued if the condition contains a variable declaration, e.g.:

int bar(); 
void foo() { 
   if (int value = bar()) { ... }  // OK 
}

If a user-deﬁned conversion operator is employed to perform implicit Boolean conversion of the controlling expression, the message is issued only if the corresponding conversion operator is not declared with the explicit keyword. For example:

struct X1 { operator bool(); }; 
struct X2 { explicit operator bool(); }; 
void foo(X1 x1, X2 x2) { 
   if (x1) { ... }    // Note 9177 
   if (x2) { ... }    // OK, explicit conversion operator 
}

The string parameter indicates the type of statement for which the non-Boolean condition appeared and is one of "do", "for", "if", or "while".
Supports AUTOSAR17 Rule A5-0-2
Supports AUTOSAR19 Rule A5-0-2
Supports MISRA C++:2008 Rule 5-0-13 - The condition of an if-statement and the condition of an iteration-statement shall have type bool.

9178
note
predicate of conditional operator has non-Boolean type type
The predicate of a conditional operator had a non-Boolean type before applying the implicit Boolean conversion. For example:

void foo(int value) { 
   value ? x() : y();        // Note 9178 
   (bool)value ? x() : y();   // OK 
   (value != 0) ? x() : y();  // OK 
}

As indicated in the above example, a cast to bool will suppress this message.

If a user-deﬁned conversion operator is employed to perform implicit Boolean conversion of the predicate, the message is issued only if the corresponding conversion operator is not declared with the explicit keyword.
Supports AUTOSAR17 Rule M5-0-14
Supports AUTOSAR19 Rule M5-0-14
Supports MISRA C++:2008 Rule 5-0-14 - The ﬁrst operand of a conditional-operator shall have type bool.

9179
note
explicit function template specialization symbol
An explicit specialization of a function template was encountered. For example:

   template <typename T> void func(T); 
   template <> void func<char>(char);   // note 9179 
   void func(int);                   // Okay

During overload resolution, specializations are considered after primary function templates. Additionally, when templated and non-templated versions of a function are available, the non-template version will be chosen if possible. These details may lead to unexpected outcomes. Function overloads are not susceptible to such issues.
Supports MISRA C++:2023 Rule 17.8.1 - Function templates shall not be explicitly specialized

9180
note
modiﬁcation of errno other than by zero assignment
errno was modiﬁed in a way other than by assignment of integer literal zero.

For example:

void f() { 
   errno = 1;  // note 9180 
   errno = 0;  // Okay 
}

Both C and C++ standard libraries contain functions that set errno to non-zero values to indicate errors. Setting errno within project code may result in confusion as to what errors were reported, and when.
Supports MISRA C++:2023 Rule 22.4.1 - The literal value zero shall be the only value assigned to errno

9181
note
switch contains fewer than two non-default switch cases
A switch was seen with fewer than two non-default cases. A switch with fewer than two cases might be better expressed as an if statement. See also message 9081 .
Supports AUTOSAR17 Rule A6-4-1
Supports AUTOSAR19 Rule A6-4-1

9183
note
qualiﬁer 'string' precedes typedef type type
This message is issued when the const or volatile qualiﬁers appear before a typedef or using name in a type speciﬁer sequence. Placing const or volatile before a typedef or using name can provide a false impression of how the qualiﬁer aﬀects the type. For example:

typedef int * INTPTR; 
volatile INTPTR counter1;  // Note 9183 
INTPTR volatile counter2;  // OK

The declaration of counter1 may lead to the incorrect impression that its type is "pointer to volatile int" instead of its actual type of "volatile pointer to non-volatile int". Analogous issues exist for the const qualiﬁer. Placing the qualiﬁer after the typedef name doesn’t change the semantic meaning but reduces the chance of misinterpreting the impact of the qualiﬁer. The string parameter is const or volatile and the type parameter contains the typedef type that follows the qualiﬁer.
Supports AUTOSAR17 Rule A7-1-3
Supports AUTOSAR19 Rule A7-1-3

9184
note
condition of #if directive is integer literal zero
A #if directive was encountered with a condition that is integer literal zero. For example:

#if 0  // note 9184 
#endif

This construct is sometimes used as an alternate method of "commenting out" code. The code found in the body of such directives will never be executed, essentially creating regions of dead code.
Supports MISRA C++:2023 Dir 5.7.2 - Sections of code should not be commented out

9185
note
assignment operator symbol declared without lvalue ref-qualiﬁer
A member assignment operator function was declared without an lvalue reference qualiﬁer, the presence of which would limit assignment to lvalue objects. Allowing assignment to rvalue class objects can result in subtle logic errors and may be confusing since assignment to rvalues of fundamental types is not possible using built-in assignment operators. Assignment operators include copy assignment, move assignment, simple assignment, and compound assignment (e.g. operator+=). A member function is declared with an lvalue reference qualiﬁer by adding & after the function’s parameter list. For example:

class X { 
   X& operator+=(int);    // Message 9185 
   X& operator-=(int) &;  // OK 
}

Supports AUTOSAR17 Rule A12-8-7
Supports AUTOSAR19 Rule A12-8-7
Supports MISRA C++:2023 Rule 15.0.2 - User-provided copy and move member functions of a class should have appropriate signatures

9186
note
non-Boolean return type type for comparison function symbol
An overloaded comparison operator function (one of operator<, operator<=, operator>, operator>=, operator==, or operator!=) was declared to return a non-dependent type other than bool. The built-in versions of these operators that operate on fundamental types, as well as the overloaded versions deﬁned in the C++ Standard library, return bool so declaring a comparison operator with a diﬀerent return type implies unconventional semantics which may be confusing.
Supports AUTOSAR17 Rule A13-2-3
Supports AUTOSAR19 Rule A13-2-3

9187
note
non-const overloaded subscript operator symbol declared without a corresponding const version
A non-const member function or member function template overloads the subscript operator and there is no corresponding const version of the function declared in the same class. It is sometimes advised that a const version of the subscript operator be provided with a non-const version. The corresponding const version is expected to have the same parameter type, ref-qualiﬁer, and volatile qualiﬁer as the non-const version. The implemented semantics of the subscript operator for some classes, such as std::map (which adds the element referenced by the subscript operator if it does not exist), may not lend itself to a const version. The symbol parameter contains the oﬀending function and can be used to suppress the message on a case-by-case basis using the -esym option. The option -esym(9187,std::*) can be used to suppress the message for classes deﬁned in the Standard C++ library.
Supports AUTOSAR17 Rule A13-5-1
Supports AUTOSAR19 Rule A13-5-1

9188
note
use of temporary array element outside of immediate read / use of temporary array outside of immediate subscript or dereference
A non-lvalue array underwent array-to-pointer decay outside of an immediate subscript/dereference expression, or a subscripted/dereferenced element of a non-lvalue array was used outside of an immediate read.

struct S { int a[5]; }; 
struct S f(void); 
void g() { 
   f().a[2] = 4;     // note 9188 
   int* p = f().a;   // note 9188 
   int i = f().a[2];  // Okay 
}

Supports MISRA C 2012 AMD3 Rule 18.9 - An object with temporary lifetime shall not undergo array-to-pointer conversion
Supports MISRA C:2023 Rule 18.9 - An object with temporary lifetime shall not undergo array-to-pointer conversion
Supports MISRA C:2025 Rule 18.9

9189
note
multiple expression statements on same line
An expression statement was encountered on the same line as another.

x++; y++; // note 9189

This note will not be issued inside of macro expansions or deﬁnitions.

Note that null statements (expression statements without an expression) do count as expression statements for the purpose of this rule.

Note that declaration initializers, comma operators, and jump statements are not expression statements, even though they may look like them. The following examples are not covered by this note:

int x = y++; x++;   // one declaration and one expression statement 
y++, x++;          // one expression statement 
if (x < y) { return x++; } else { return y++; }   // return is jump statement

Supports AUTOSAR19 Rule A7-1-7

9191
note
multiple loop counters in for loop
More than one for loop counter was detected inside of a for loop. See message 850 for the deﬁnition of a for loop counter.

for (int x=0, y=10; x < 10 && y > 0; x++, y--)  // note 9191

Supports AUTOSAR17 Rule A6-5-2
Supports AUTOSAR19 Rule A6-5-2
Supports MISRA C 2012 Rule 14.2 - A for loop shall be well-formed
Supports MISRA C:2023 Rule 14.2 - A for loop shall be well-formed
Supports MISRA C:2025 Rule 14.2
Supports MISRA C++:2008 Rule 6-5-1 - A for loop shall contain a single loop-counter which shall not have ﬂoating type.

9192
note
no loop counter in string for loop
No for loop counter was detected inside of the for loop. See message 850 for the deﬁnition of a for loop counter.

for (int x = 0; x < 10;)  // note 9192

The string parameter will either be the string "empty", to denote a for loop that does not have an init-statement, condition, or iteration-expression, or it will be an empty string for all other for loops.
Supports AUTOSAR17 Rule A6-5-2
Supports AUTOSAR19 Rule A6-5-2
Supports MISRA C 2012 Rule 14.2 - A for loop shall be well-formed
Supports MISRA C:2023 Rule 14.2 - A for loop shall be well-formed
Supports MISRA C:2025 Rule 14.2
Supports MISRA C++:2008 Rule 6-5-1 - A for loop shall contain a single loop-counter which shall not have ﬂoating type.

9193
note
loop counter symbol not modiﬁed by increment or decrement of a constant amount
A for loop counter was modiﬁed other than by an increment, decrement, or compound addition/subtraction by a constant expression. See message 850 for the deﬁnition of a for loop counter.

 for (int x = 0; x < 10; x += fn())  // note 9191

Supports AUTOSAR17 Rule M6-5-4
Supports AUTOSAR19 Rule M6-5-4
Supports MISRA C++:2008 Rule 6-5-4 - The loop-counter shall be modiﬁed by one of: –, ++, -=n, or +=n; where n remains constant for the duration of the loop.

9194
note
variable symbol is modiﬁed in for condition|expression, but is not a loop counter
A for loop control variable other than a for loop counter was modiﬁed in the for loop condition or iteration-expression. See message 850 for the deﬁnition of a for loop counter.

for (int x = 0; x < 10; i++, x++)  // note 9194

For the purpose of this message, the MISRA C++ 2008 deﬁnition of a for loop control variable is used. A for loop control variable is deﬁned as any variable that is present in the for loop init-statement, condition, or iteration-expression. PC-lint Plus does not consider any variable declared in the init-statement and not used in the condition or iteration-expression to be a for loop control variable.
Supports AUTOSAR17 Rule M6-5-5
Supports AUTOSAR19 Rule M6-5-5
Supports MISRA C 2012 Rule 14.2 - A for loop shall be well-formed
Supports MISRA C:2023 Rule 14.2 - A for loop shall be well-formed
Supports MISRA C:2025 Rule 14.2
Supports MISRA C++:2008 Rule 6-5-5 - A loop-control-variable other than the loop-counter shall not be modiﬁed within condition or expression.

9195
note
variable symbol is potentially modiﬁed in for condition|expression, but is not a loop counter
A for loop control variable other than a for loop counter was potentially modiﬁed in the for loop condition or iteration-expression. See message 850 for the deﬁnition of a for loop counter. See message 9194 for the deﬁnition of a for loop control variable.

void test(int*); 
for (int x = 0; x < 10 && test(&flag); x++)  // note 9195

Note that if a modiﬁcation can be determined to absolutely occur, then message 9194 will be issued instead. Non-const class operator overloads of builtin operators that modify their operands are considered to alway modify.
Supports AUTOSAR17 Rule M6-5-5
Supports AUTOSAR19 Rule M6-5-5
Supports MISRA C 2012 Rule 14.2 - A for loop shall be well-formed
Supports MISRA C:2023 Rule 14.2 - A for loop shall be well-formed
Supports MISRA C:2025 Rule 14.2
Supports MISRA C++:2008 Rule 6-5-5 - A loop-control-variable other than the loop-counter shall not be modiﬁed within condition or expression.

9196
note
variable symbol is used in for statement and modiﬁed in for body, but is not a Boolean
A for loop control variable other than a for loop counter was modiﬁed in the body of the for loop, but does not have a Boolean type. See message 850 for the deﬁnition of a for loop counter. See message 9194 for the deﬁnition of a for loop control variable.

int end; 
for (int x = 0; x < 10 && x < end; x++) { 
   end = getEnd();  // note 9196 
}

A common use for the for loop control variable is to terminate a loop early. The logic of the for loop condition could be easier to understand if the for loop control variable is a Boolean whose state is simple, and whose more complex state change is done in the body of the loop.

Note: This message will not be emitted in C++ mode when Boolean types have been disable via the -fbo ﬂag option. In C modules, the MISRA C 2012 Essentially Boolean type will be considered.
Supports AUTOSAR17 Rule M6-5-6
Supports AUTOSAR19 Rule M6-5-6
Supports MISRA C 2012 Rule 14.2 - A for loop shall be well-formed
Supports MISRA C:2023 Rule 14.2 - A for loop shall be well-formed
Supports MISRA C:2025 Rule 14.2
Supports MISRA C++:2008 Rule 6-5-6 - A loop-control-variable other than the loop-counter which is modiﬁed in statement shall have type bool.

9197
note
statement present in for loop init-statement that does not assign the value of a loop counter
A for loop init-statement contains a statement which does not assign the value of a loop counter. See message 850 for the deﬁnition of a for loop counter.

for (int x = 0, y = 0; x < 10; x++);  // note 9197

Supports MISRA C 2012 Rule 14.2 - A for loop shall be well-formed
Supports MISRA C:2023 Rule 14.2 - A for loop shall be well-formed
Supports MISRA C:2025 Rule 14.2

9202
note
bitﬁeld symbol declared as member of union symbol
A bitﬁeld was declared as the member of a union. This is unusual as bitﬁelds are typically used within structures to save space but all members of a union occupy the same space so that beneﬁt does not apply. Bitﬁelds are also not useful for type punning purposes as the location of the bits corresponding to the bitﬁeld are implementation deﬁned.
Supports MISRA C 2012 AMD3 Rule 6.3 - A bit ﬁeld shall not be declared as a member of a union
Supports MISRA C:2023 Rule 6.3 - A bit ﬁeld shall not be declared as a member of a union
Supports MISRA C:2025 Rule 6.3

9203
note
declaration of symbol contains an alignment attribute whose expression evaluates to zero
An alignment attribute (such as alignas or _Alignas) was encountered in the declaration of the speciﬁed symbol with an integer constant expression that evaluated to a zero value. While valid, such attributes are ignored so their presence is suspicious. If the expression is the result of a macro expansion, this message may be suppressed using -emacro .
Supports MISRA C 2012 AMD3 Rule 8.16 - The alignment speciﬁcation of zero should not appear in an object declaration
Supports MISRA C:2023 Rule 8.16 - The alignment speciﬁcation of zero should not appear in an object declaration
Supports MISRA C:2025 Rule 8.16

9204
note
hexadecimal escape sequence used
A hexadecimal escape sequence (\x) was used inside a character or string literal.
Supports MISRA C 2004 Rule 4.1 - Only those escape sequences that are deﬁned in the ISO C standard shall be used.

9205
note
declaration of symbol contains multiple alignment attributes
Multiple alignment attributes were encountered in the declaration of the speciﬁed symbol. When multiple alignment attributes are provided, all but the strictest one is ignored rendering the other attributes superﬂuous.
Supports MISRA C 2012 AMD3 Rule 8.17 - At most one explicit alignment speciﬁer should appear in an object declaration
Supports MISRA C:2023 Rule 8.17 - At most one explicit alignment speciﬁer should appear in an object declaration
Supports MISRA C:2025 Rule 8.17

9206
note
function symbol with dependent return type type does not use trailing return type or return type deduction
A function template declaration with a dependent return type is not using either function return type deduction or trailing-return-type syntax.

template <typename T> 
typename DataClass<T>::type initZero(void) {  // note 9206 
   return DataClass<T>{0}.get(); 
}

When using function return type deduction or trailing-return-type syntax, the return type may omit full qualiﬁcation and the typename keyword, which is less complex.

This message does not get emitted for conversion functions.
Supports AUTOSAR17 Rule A8-2-1
Supports AUTOSAR19 Rule A8-2-1

9207
note
built-in unary plus operator encountered
The unary plus operator was encountered which did not result in a call to an overloaded operator function. The eﬀects of the built-in unary plus operator can be achieved more directly by using casts which may make the intention more explicit and reduce the potential for confusion. For example:

void baz(short); 
void baz(int); 
 
void foo(signed char sc) { 
   baz(+sc);                // Note 9207 
   baz(static_cast<int>(sc));  // Okay 
}

Supports MISRA C++:2023 Rule 8.3.2 - The built-in unary + operator should not be used

9208
note
generic selection does not contain any non-default associations
A generic selection was encountered whose only provided association was a default association. Generic selections provide a mechanism to produce a value that is dependent on the type of a controlling expression. A generic selection that only contains a default association will always produce a value that is independent of its controlling expression making its use superﬂuous.
Supports MISRA C 2012 AMD3 Rule 23.3 - A generic selection should contain at least one non-default association
Supports MISRA C:2023 Rule 23.3 - A generic selection should contain at least one non-default association
Supports MISRA C:2025 Rule 23.3

9209
note
plain character data used with prohibited operator string
The plain char type is deﬁned by the implementation to have the same size and range as either signed char or unsigned char but is a separate and distinct type. For this reason, it is often recommended that char be used for character data and signed char and unsigned char be used for numeric data. This message reports when an object of plain char type is used as an operand to a unary operator or a binary operator other than =, ==, and !=.
Supports CERT C STR09-C - Don’t assume numeric values for expressions with type plain character
Supports MISRA C 2004 Rule 6.1 - The plain char type shall be used only for storage and use of character values.

9210
note
default association does not appear as either the ﬁrst or the last association of generic selection
A generic selection was encountered with a default association that does not appear as either the ﬁrst or last in the association list. Placing default associations at the beginning or end of the association list helps them to stand out and clariﬁes the intent of the selection structure.
Supports MISRA C 2012 AMD3 Rule 23.8 - A default association shall appear as either the ﬁrst or the last association of a generic selection
Supports MISRA C:2023 Rule 23.8 - A default association shall appear as either the ﬁrst or the last association of a generic selection
Supports MISRA C:2025 Rule 23.8

9211
note
generic selection is not expanded from a function-like macro
A generic selection was encountered which was not expanded from a function-like macro and whose controlling expression is not the result of a macro argument’s expansion. When a generic selection is employed outside of a macro expansion, the type of the controlling expression is predetermined so querying it is not necessary.
Supports MISRA C 2012 AMD3 Rule 23.1 - A generic selection should only be expanded from a macro
Supports MISRA C:2023 Rule 23.1 - A generic selection should only be expanded from a macro
Supports MISRA C:2025 Rule 23.1

9212
note
bit ﬁeld type type is not explicitly signed int or unsigned int
A bit ﬁeld was deﬁned with a type other than signed int or unsigned int or with a typedef that is deﬁned using one of these two explicit types. When using plain int as a bit-ﬁeld type, the signedness of the type used is implementation deﬁned. Only int (signed and unsigned) and _Bool (in C99) are sanctioned for use in bit-ﬁelds, use of any other type results in implementation-deﬁned behavior. -etype(9212, _Bool) can be used to suppress this message for the C99 _Bool type. See also message 9149 , which is similar but more lenient.
Supports MISRA C 2004 Rule 6.4 - Bit ﬁelds shall only be deﬁned to be of type unsigned int or signed int.
Supports MISRA C++:2023 Rule 12.2.2 - A bit-ﬁeld shall have an appropriate type

9213
note
controlling expression contains a call to function symbol which will not be called
The controlling expression of a generic-selection contains a function call. The controlling expression is only used for its type and therefore, the function will not be called. The related message 2419 will report controlling expressions containing a side eﬀect. For example:

int x = 0; 
int foo() { return 0; } 
_Generic(x++,  int: 1, default: 0); // Warning 2419 
_Generic(foo(), int: 1, default: 0); // Note 9213

9214
note
default association will be selected because type is not implicitly converted to type
A generic-selection was encountered that selected a default association when an implicit pointer conversion might have been expected. Unlike arguments passed to a function, the type of the controlling expression is not implicitly converted to match an association. Since qualiﬁers must match exactly, selecting the default association might be surprising behavior. For example:

char* S = "Hello!"; 
void foo(const char* str); 
foo(S);                            // OK 
_Generic(S, const char*: 1, default: 0); // Note 9214, selects default

This message is only issued when the type of the controlling expression is a pointer or null pointer constant.
Supports MISRA C 2012 AMD3 Rule 23.5 - A generic selection should not depend on implicit pointer type conversion
Supports MISRA C:2023 Rule 23.5 - A generic selection should not depend on implicit pointer type conversion
Supports MISRA C:2025 Rule 23.5

9215
note
unnamed parameter for 'virtual/non-virtual' function symbol
This message is emitted when an unnamed function parameter is encountered in the deﬁnition of a function.
Supports AUTOSAR17 Rule M0-1-11
Supports MISRA C++:2008 Rule 0-1-11 - There shall be no unused parameters (named or unnamed) in non-virtual functions.
Supports MISRA C++:2008 Rule 0-1-12 - There shall be no unused parameters (named or unnamed) in the set of parameters for a virtual function and all the functions that override it.

9216
note
essential type of the controlling expression 'string' does not match its standard type type
The selected association of a generic selection is not consistent with the MISRA C 2012 essential type of the controlling expression. This message is not applied when the controlling expression is an integer constant expression that is neither a character constant nor boolean. For example:

short s = 0; 
_Generic(s + s, int: 0, short: 1);  // Note 9216 (selects int, essentially short) 
_Generic('c', int: 0, char: 1);     // Note 9216 (selects int, essentially char) 
_Generic(25 + 35, int: 0, short: 1); // OK, integer constant expression

This message is not emitted in C++.
Supports MISRA C 2012 AMD3 Rule 23.6 - The controlling expression of a generic selection shall have an essential type that matches its standard type
Supports MISRA C:2023 Rule 23.6 - The controlling expression of a generic selection shall have an essential type that matches its standard type
Supports MISRA C:2025 Rule 23.6

9217
note
assembly language instruction within a function
An assembly language instruction was encountered inside of a function. This message complements message 9220 and may be used in combination with it to report on all use of assembly language. For example:

asm("NOP");  // Note 9220 
void foo() { 
   asm("NOP");  // Note 9217 
}

Message 9221 will be issued if a function contains a mix of assembly code and non-assembly code.
Supports MISRA C++:2023 Rule 10.4.1 - The asm declaration shall not be used

9218
note
arguments to type-generic macro 'macro' resulting in call to function symbol have diﬀerent types type and type
The operand arguments passed to a multi-argument type-generic macro deﬁned in tgmath.h have diﬀerent standard types. All arguments to such macros should have the same standard type, after integer promotion has been applied to any integer arguments. This generally clariﬁes the relationship between input and outputs as well as handling platform speciﬁc cases where the deduced common real type may be an unexpected size or lose precision.

float f; 
double d; 
pow(f, d); // Note 9218 
pow(f, f); // No message issued

Supports MISRA C 2012 AMD3 Rule 21.23 - All operand arguments to any multi-argument type-generic macros declared in <tgmath.h> shall have the same standard type
Supports MISRA C:2023 Rule 21.23 - All operand arguments to any multi-argument type-generic macros declared in <tgmath.h> shall have the same standard type
Supports MISRA C:2025 Rule 21.23

9219
note
parameter integer of generic selection macro 'macro' is not evaluated exactly once
The macro argument appearing in the controlling expression of an expanded generic-selection is not evaluated exactly once. The arguments in a controlling expression are only used for their type and are never evaluated. The macro argument should be expanded in each of the result expressions or elsewhere in the macro body, and the number of times it is evaluated should not depend on which association is selected. An exception is made if all of the result expressions are constant expressions and the macro argument never expands outside of the controlling expression. For example:

#define gen1(X) _Generic((X), float: funcf(X), default: 0) // Note 9219 
#define gen2(X) (_Generic((X), float: funcf, default: funcl) (X)) // OK 
#define gen3(X) _Generic((X), float: 1, default: 0) // OK, exception

This message does not depend on the presence of side eﬀects in the operand expression.
Supports MISRA C 2012 AMD3 Rule 23.7 - A generic selection that is expanded from a macro should evaluate its argument only once
Supports MISRA C:2023 Rule 23.7 - A generic selection that is expanded from a macro should evaluate its argument only once
Supports MISRA C:2025 Rule 23.7

9220
note
assembly language instruction is not encapsulated in a function
An assembly language instruction was not encapsulated in a function. Isolating assembly language to its own function can aid in portability. For example:

asm("NOP");  // Note 9220 
void foo() { 
   asm("NOP");  // Note 9217 
}

See also 9217 and 9221 .
Supports AUTOSAR17 Rule M7-4-3
Supports AUTOSAR19 Rule M7-4-3
Supports MISRA C 2004 Rule 2.1 - Assembly language shall be encapsulated and isolated.
Supports MISRA C 2012 Dir 4.3 - Assembly language shall be encapsulated and isolated
Supports MISRA C:2023 Dir 4.3 - Assembly language shall be encapsulated and isolated
Supports MISRA C:2025 Dir 4.3
Supports MISRA C++:2008 Rule 7-4-3 - Assembly language shall be encapsulated and isolated.
Supports MISRA C++:2023 Rule 10.4.1 - The asm declaration shall not be used

9221
note
function symbol mixes assembly code with non-assembly code
An assembly language instruction was encountered in a function that contained non-assembly language code. Isolating assembly language code to its own function can aid in portability. For example:

void foo() {  // Note 9221 
   asm("NOP"); 
   bar(); 
}

If an assembly language instruction appears outside of a function, message 9220 will be reported.
Supports AUTOSAR17 Rule M7-4-3
Supports AUTOSAR19 Rule M7-4-3
Supports MISRA C 2004 Rule 2.1 - Assembly language shall be encapsulated and isolated.
Supports MISRA C 2012 Dir 4.3 - Assembly language shall be encapsulated and isolated
Supports MISRA C:2023 Dir 4.3 - Assembly language shall be encapsulated and isolated
Supports MISRA C:2025 Dir 4.3
Supports MISRA C++:2008 Rule 7-4-3 - Assembly language shall be encapsulated and isolated.

9222
note
small integer variant of a minimum-width integer constant macro 'macro' is used
A minimum-width integer constant macro was used whose width is less than that of type int. Many implementations of the integer constant macros that are smaller than an int will just expand to the argument like this:

#define UINT8_C(x)  (x)

This will result in an expression with type int and not of the type anticipated by the macro. For example:

_Generic(UINT8_C(100), uint8_t: 1, int: 0);  // int association is selected

Supports MISRA C 2012 AMD4 Rule 7.6 - The small integer variants of the minimum-width integer constant macros shall not be used
Supports MISRA C:2023 Rule 7.6 - The small integer variants of the minimum-width integer constant macros shall not be used
Supports MISRA C:2025 Rule 7.6

9223
note
value is modiﬁed using a pointer member with a const-qualiﬁed base symbol
A value was modiﬁed through a pointer on a const-qualiﬁed object. While a pointer ﬁeld of a const-qualiﬁed object itself cannot be modiﬁed, the value it points to can be. In some cases, declaring an object const can come with the expectation that the object will only be used for reading. For example:

struct S { 
   int* x; 
   char* y; 
}; 
 
void foo(const struct S* a) { 
   (*a->x)++;  // note 9223 
   a->y[0] = '-';  // note 9223 
}

Supports CERT C ENV30-C - Do not modify the object referenced by the return value of certain functions
Supports MISRA C 2012 AMD1 Rule 21.19 - The pointers returned by the Standard Library functions localeconv, getenv, setlocale or, strerror shall only be used as if they have pointer to const-qualiﬁed type
Supports MISRA C:2023 Rule 21.19 - The pointers returned by the Standard Library functions localeconv, getenv, setlocale or, strerror shall only be used as if they have pointer to const-qualiﬁed type
Supports MISRA C:2025 Rule 21.19

9224
note
expression is not eﬀectively boolean and must be explicitly tested for zero
An expression that is not "eﬀectively Boolean" is being implicitly tested for zero. For example, given that x is an int:

if (x)

will elicit this message while:

if (x != 0)

will not.

"Eﬀectively Boolean" values are produced by the operators ==, !=, <=, >=, <, >, !, ||, and &&. An expression will also be considered "eﬀectively Boolean" if the Strong Type of the expression is Boolean.
Supports MISRA C 2004 Rule 13.2 - Tests of a value against zero should be made explicit, unless the operand is eﬀectively Boolean.

9225
note
integral expression of underlying type underlying-type cannot be implicitly converted to type type because it is not a wider integer type of the same signedness
An integral expression was implicitly converted to a type that was not a wider type of the same signedness.
Supports MISRA C 2004 Rule 10.1 - The value of an expression of integer type shall not be implicitly converted to a diﬀerent underlying type if: a) it is not a conversion to a wider integer type of the same signedness, or b) the expression is complex, or c) the expression is not constant and is a function argument, or d) the expression is not constant and is a return expression.

9226
note
integral expression of underlying type underlying-type cannot be implicitly converted to type type because it is string
A complex integral expression was implicitly converted to a diﬀerent type or a non-constant integral expression was implicitly converted to a diﬀerent type while being passed to or returned from a function. "Complex" here means an expression that is not an lvalue and is not a function return value.
Supports MISRA C 2004 Rule 10.1 - The value of an expression of integer type shall not be implicitly converted to a diﬀerent underlying type if: a) it is not a conversion to a wider integer type of the same signedness, or b) the expression is complex, or c) the expression is not constant and is a function argument, or d) the expression is not constant and is a return expression.

9227
note
ﬂoating expression of underlying type underlying-type cannot be implicitly converted to type type because it is not a wider ﬂoating type
A ﬂoating point expression was implicitly converted to a type that is not a wider type.
Supports MISRA C 2004 Rule 10.2 (Req) - The value of an expression of ﬂoating type shall not be implicitly converted to a diﬀerent type if: (a) it is not a conversion to a wider ﬂoating type, or
(b) the expression is complex, or
(c) the expression is a function argument, or
(d) the expression is a return expression
Supports CERT C FLP03-C - Detect and handle ﬂoating-point errors
Supports CERT C FLP34-C - Ensure that ﬂoating-point conversions are within range of the new type
Supports CWE-197 - Numeric Truncation Error
Supports CWE-369 - Divide By Zero
Supports CWE-681 - Incorrect Conversion between Numeric Types
Supports MISRA C 2004 Rule 10.2 - The value of an expression of ﬂoating type shall not be implicitly converted to a diﬀerent type if: a) it is not a conversion to a wider ﬂoating type, or b) the expression is complex, or c) the expression is a function argument, or d) the expression is a return expression.

9228
note
ﬂoating expression of underlying type underlying-type cannot be implicitly converted to type type because it is string
A ﬂoating point expression was implicitly converted to a diﬀerent type in a context in which a cast should be used to be compliant with MISRA C 2004. The context is provided in string, which is one of a complex expression, a function argument, or a return value.
Supports MISRA C 2004 Rule 10.2 (Req) - The value of an expression of ﬂoating type shall not be implicitly converted to a diﬀerent type if: (a) it is not a conversion to a wider ﬂoating type, or
(b) the expression is complex, or
(c) the expression is a function argument, or
(d) the expression is a return expression
Supports MISRA C 2004 Rule 10.2 - The value of an expression of ﬂoating type shall not be implicitly converted to a diﬀerent type if: a) it is not a conversion to a wider ﬂoating type, or b) the expression is complex, or c) the expression is a function argument, or d) the expression is a return expression.

9229
note
complex integral expression may only be cast to another integral type of the same signedness no wider than the original type
A complex expression with integral type was cast to a type with diﬀerent signedness or whose underlying type is wider than the underlying type of the expression.
Supports MISRA C 2004 Rule 10.3 - The value of a complex expression of integer type may only be cast to a type that is narrower and of the same signedness as the underlying type of the expression.

9230
note
complex ﬂoating expression may only be cast to another ﬂoating type no wider than the original type
A complex expression with ﬂoating point type was cast to a type with whose underlying type is wider than the underlying type of the expression.

Supports MISRA C 2004 Rule 10.4 - The value of a complex expression of ﬂoating type may only be cast to a narrower ﬂoating type.

9231
note
result of operator operator applied to operand of type type must be immediately cast to type
The ~ or << operator was applied to an operand with a MISRA C underlying type of unsigned char or unsigned short but the result was not cast to the appropriate underlying type.
Supports MISRA C 2004 Rule 10.5 - If the bitwise operators ~ and « are applied to an operand of underlying type unsigned char or unsigned short, the result shall be immediately cast to the underlying type of the operand.

9232
note
expected/did not expect an eﬀectively boolean argument for operator operator
An "eﬀectively Boolean" expression was used as an operand to an operator that should not operate on such an expression, or an operator for which an "eﬀectively Boolean" expression was expected was not provided one. Speciﬁcally, the operators &&, ||, and ! should contain only "eﬀectively Boolean" operands and "eﬀectively Boolean" operands should not be used with operators other than &&, ||, !, =, ==, !=, and ?:. See the description of 9224 for more information on what is considered "eﬀectively Boolean".
Supports MISRA C 2004 Rule 12.6 - The operands of logical operators (&&, || and !) should be eﬀectively Boolean. Expressions that are eﬀectively Boolean should not be used as operands to operators other than (&&, || and !).

9233
note
bitwise operator operator may not be applied to operand with signed underlying type
An expression with a MISRA C signed underlying type was provided as an operand to a bitwise operator.
Supports CERT C INT13-C - Use bitwise operators only on unsigned operands
Supports CWE-682 - Incorrect Calculation
Supports MISRA C 2004 Rule 12.7 - Bitwise operators shall not be applied to operands whose underlying type is signed.

9234
note
shift amount exceeds size of operand's underlying type
An expression was shifted by a negative amount or an amount greater than the bit width of the expression’s MISRA C underlying type.
Supports MISRA C 2004 Rule 12.8 - The right-hand operand of a shift operator shall lie between zero and one less than the width in bits of the underlying type of the left-hand operand.

9235
note
unary minus applied to operand with unsigned underlying type
The unary minus operator was applied to an expression with an unsigned MISRA C underlying type.
Supports MISRA C 2004 Rule 12.9 - The unary minus operator shall not be applied to an expression whose underlying type is unsigned.

9236
note
assignment operator may not be used within a boolean-valued expression
An assignment operator was used within a Boolean context, such as comparing the result of assignment to a speciﬁc value.
Supports MISRA C 2004 Rule 13.1 - Assignment operators shall not be used in expressions that yield a Boolean value.

9237
note
conversion between pointer to function type type and diﬀering non-integral type type
A conversion was performed between a pointer to function and a pointer to a diﬀerent type that was not a pointer to an integral type.
Supports MISRA C 2004 Rule 11.1 - Conversions shall not be performed between a pointer to a function and any type other than an integral type.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

9238
note
switch condition may not be boolean
The conditional expression of a switch statement has an "eﬀectively Boolean" type. See the description of 9224 for more information on what is considered "eﬀectively Boolean".
Supports MISRA C 2004 Rule 15.4 - A switch expression shall not represent a value that is eﬀectively Boolean.

9239
note
opposite operators symbol and symbol are deﬁned and neither are deﬁned in terms of the other
Two opposite operators were deﬁned where one was not deﬁned in terms of the other. Deﬁning an operator in terms of its opposite simpliﬁes maintenance and reduces the risk for error. Opposite operators are == and !=, <= and >, >= and <.

inline bool operator ==(const A& lhs, const A& rhs) { 
   return lhs.value == rhs.value; 
} 
inline bool operator !=(const A& lhs, const A& rhs) { // Note 9239 
   return lhs.value != rhs.value; 
} 
 
inline bool operator ==(const B& lhs, const B& rhs) { 
   return lhs.value == rhs.value; 
} 
inline bool operator !=(const B& lhs, const B& rhs) { // OK 
   return !(lhs == rhs); 
}

Completeness of relational operators can be achieved by implementing just operator== and operator< and using namespace rel_ops.
Supports AUTOSAR19 Rule A13-5-4

9240
note
left/right side of logical operator 'operator' is not a primary expression
This message is issued when the operands of the || and && operators are not primary-expressions.
Supports MISRA C 2004 Rule 12.5 - The operands of a logical && or || shall be primary-expressions.

9241
note
left/right side of logical operator 'operator' is an unparethesized binary operator
An unparenthesized binary operator expression was used as an operand to the logical operators && and ||. For the purpose of this message any member access operators, function call operators, or the comma operator are not considered binary operators.

int fn(int a, int b, int c) { 
   return (a < b && c);  // note 9241 
}

Supports AUTOSAR19 Rule A5-2-6

9242
note
struct symbol declares a protected/private data member symbol
A class type deﬁned using the struct keyword has a non-public data member.

struct B { 
protected: 
   int x;  // note 9242 
};

For structs that use static data members see message 9243 . For structs that use methods see message 9244 . For structs that inherit from other classes see message 9245 . For classes that inherit from structs see message 9246 . For structs that are not a POD data type see message 9437 .
Supports AUTOSAR17 Rule A11-0-2
Supports AUTOSAR19 Rule A11-0-2

9243
note
struct symbol declares a static/thread storage duration data member symbol
A class type deﬁned using the struct keyword has a static or thread storage duration data member.

struct B { 
   static int x;  // note 9243 
};

For structs that use non-public data members see message 9242 . For structs that use methods see message 9244 . For structs that inherit from other classes see message 9245 . For classes that inherit from structs see message 9246 . For structs that are not a POD data type see message 9437 .
Supports AUTOSAR17 Rule A11-0-2
Supports AUTOSAR19 Rule A11-0-2

9244
note
struct symbol declares a method symbol
A class type deﬁned using the struct keyword has declared a method or user deﬁned, non-defaulted non-deleted special member function.

struct B { 
 void fn();  // note 9244 
};

For structs that use non-public data members see message 9242 . For structs that use static data members see message 9243 . For structs that inherit from other classes see message 9245 . For classes that inherit from structs see message 9246 . For structs that are not a POD data type see message 9437 .
Supports AUTOSAR17 Rule A11-0-2
Supports AUTOSAR19 Rule A11-0-2

9245
note
struct symbol inherits from base class symbol
A class type deﬁned using the struct keyword inherits from another class.

class Base {}; 
struct Child : Base {};  // note 9245

For structs that use non-public data members see message 9242 . For structs that use static data members see message 9243 . For structs that use methods see message 9244 . For classes that inherit from structs see message 9246 . For structs that are not a POD data type see message 9437 .
Supports AUTOSAR17 Rule A11-0-2
Supports AUTOSAR19 Rule A11-0-2

9246
note
struct symbol used in base class list of symbol
A class has inherited from a class type that was declared using the struct keyword.

struct Base {}; 
class Child : Base {};  // note 9246

For structs that use non-public data members see message 9242 . For structs that use static data members see message 9243 . For structs that use methods see message 9244 . For structs that inherit from other classes see message 9245 . For structs that are not a POD data type see message 9437 .
Supports AUTOSAR17 Rule A11-0-2
Supports AUTOSAR19 Rule A11-0-2

9248
note
non-member generic function symbol declared in a namespace containing class, struct, enum, or union type declarations
A non-member generic function was declared in a namespace that contains a class, struct, enum, or union declaration. A generic function appearing in an associated namespace is considered by argument-dependent lookup for overload resolution, which can result in unexpected behavior. For example:

template <typename T> struct A { 
   A() { func(*this, 1); }  // calls NS::func 
}; 
 
template <typename T> void func(A<T> a, long b); 
 
namespace NS { 
   struct B {}; 
   template <typename T> void func(T a, int b);  // note 9248 
} 
 
A<NS::B> a;

Supports AUTOSAR19 Rule A14-5-3
Supports MISRA C++:2008 Rule 14-5-1 - A non-member generic function shall only be declared in a namespace that is not an associated namespace.

9249
note
class symbol inherits from multiple bases that contain the identiﬁer 'string'
A class directly inherits from two or more base classes that each contain a declaration with the same identiﬁer. Virtual base classes may be inherited from in multiple base classes and will not have their identiﬁers considered multiple times. A friend declaration or a using-declaration are not considered to introduce an identiﬁer into a class for the purposes of this message.

class A { int x; }; 
class B { int x; }; 
class C : public A, public B {};  // note 9249

Full qualiﬁcation would be needed to unambiguously access these members in most cases, which makes access cumbersome and removes the eﬀect of virtual members.
Supports AUTOSAR17 Rule M10-2-1
Supports AUTOSAR19 Rule M10-2-1
Supports MISRA C++:2008 Rule 10-2-1 - All accessible entity names within a multiple inheritance hierarchy should be unique.

9250
note
unqualiﬁed name lookup of 'string' in class template symbol with dependent base class
A class member was referenced with unqualiﬁed lookup inside the context of a class template, however this member’s identiﬁer was found inside of a dependent base class. Due to language rules this lookup would resolve any matching entity outside of that dependent base class, which might subvert developer expectations.

int x; 
struct Base { int x; }; 
 
template<typename T> 
class C : T { 
   void fn(void) { 
      x;       // note 9250 
      T::x;    // Okay 
      this->x;  // Okay 
   } 
}; 
template class C<Base>;

Qualifying the class member with a namespace name or class name, or preﬁxing with this->, resolves the ambiguity.
Supports AUTOSAR17 Rule M14-6-1
Supports AUTOSAR19 Rule M14-6-1
Supports MISRA C++:2008 Rule 14-6-1 - In a class template with a dependent base, any name that may be found in that dependent base shall be referred to using a qualiﬁed-id or this->
Supports MISRA C++:2023 Rule 6.4.3 - A name that is present in a dependent base shall not be resolved by unqualiﬁed lookup

9251
note
integer literal 'string' has a suﬃx associated with a long int type but a value that requires a wider type
An integer literal was encountered that contained an l or L suﬃx but with a value that cannot be represented in a long integer type. For example:

foo(111222333444UL);  // note 9251 (assuming 32-bit long and 64-bit long long) 
foo(111222333444ULL);  // Okay

Using an ll or LL suﬃx may make it clearer that the integer literal has a type wider than long.
Supports MISRA C++:2023 Rule 5.13.6 - An integer-literal of type long long shall not use a single L or l in any suﬃx

9252
note
testing ﬂoating point for equality using exact value
Message 777 is issued when an object with a ﬂoating point type is tested for equality using either == or !=. Message 777 is not issued when one of the operands is a value that can be represented exactly in the corresponding ﬂoating point representation, such as 0 or 13.5. In such cases, this message is issued instead.
Supports AUTOSAR17 Rule M6-2-2
Supports AUTOSAR19 Rule M6-2-2
Supports CERT C FLP00-C - Understand the limitations of ﬂoating-point numbers
Supports CERT C FLP02-C - Avoid using ﬂoating-point numbers when precise computation is needed
Supports MISRA C 2004 Rule 13.3 - Floating-point expressions shall not be tested for equality or inequality.
Supports MISRA C++:2008 Rule 6-2-2 - Floating-point expressions shall not be directly or indirectly tested for equality or inequality.

9253
note
bit-ﬁeld symbol declared
A bit-ﬁeld was declared. For example:

struct S { 
   char *str; 
   int val : 10;  // note 9253 
};

The use of bit-ﬁelds may warrant special consideration as associated implementation deﬁned behavior can result in portability concerns.
Supports MISRA C++:2023 Rule 12.2.1 - Bit-ﬁelds should not be declared

9254
note
continue statement encountered
A continue statement was seen. Some coding guidelines forbid the use of continue statements.
Supports MISRA C 2004 Rule 14.5 - The continue statement shall not be used.

9255
note
global declaration of inline namespace symbol
An inline namespace was declared in the global namespace.

inline namespace A {}  // note 9255

See message 9141 for other declarations that occur in the global namespace.
Supports MISRA C++:2023 Rule 6.0.3 - The only declarations in the global namespace should be main, namespace declarations and extern "C" declarations

9256
note
declaration of symbol uses volatile qualiﬁer detail
The volatile qualiﬁer has been applied to one of the following:

local variable
function parameter
return type
member function
structured binding

volatile int fn(); // note 9256

It is generally not well understood what volatile should do in these contexts, and compiler implementations may vary. The detail parameter will either be empty or "in return type" for a volatile function return type to distinguish it from a volatile member function.
Supports MISRA C++:2023 Rule 10.1.2 - The volatile qualiﬁer shall be used appropriately

9257
note
local non-const variable symbol has string storage duration
A block scope variable was declared with either static or thread (indicated by the string parameter) storage duration and was not declared as const or constexpr. For example:

void foo() { 
   static int count = 0;  // note 9257 
   /* ... */ 
}

Such variables are typically used to maintain state information in function implementations which may increase complexity and can introduce thread-unsafe conditions or reentrant race conditions.
Supports MISRA C++:2023 Rule 6.7.1 - Local variables shall not have static storage duration

9259
note
C comment contains '://' sequence
Message 9059 reports on cases where a C comment contains what may be a C++ comment, e.g. the sequence ’//’. Because including URLs inside of comments is a common practice, message 9059 is not issued when the ’//’ sequence is immediately preceded by a ’:’ to prevent the message from being issued in cases such as:

/* See https://example.com for details */

This message ﬁlls the gap by reporting on the instances not reported by 9059 .
Supports CERT C MSC04-C - Use comments consistently and in a readable fashion

9260
note
C++ style comment used
A C++-style comment (//) was encountered. Such comments were not part of C until C99 and may not be consistently supported by older compilers.
Supports MISRA C 2004 Rule 2.2 - Source code shall only use C-style comments.

9264
note
array subscript applied to variable symbol declared with non-array type type
The base of an array subscript operation was not declared as an array (i.e., it was declared as a pointer). Some coding guidelines suggest that array subscript operations should only be applied to array types.
Supports AUTOSAR17 Rule M5-0-15
Supports AUTOSAR19 Rule M5-0-15
Supports MISRA C 2004 Rule 17.4 - Array indexing shall be the only allowed form of pointer arithmetic.
Supports MISRA C++:2008 Rule 5-0-15 - Array indexing shall be the only form of pointer arithmetic.

9265
note
[left/right operand] to operator 'operator' is inappropriate: detail
The built-in type classiﬁcation of an operand of a bitwise or shift operator or the value of a constant shift amount was inappropriate for the purposes of a related coding standard.
Supports MISRA C++:2023 Rule 7.0.4 - The operands of bitwise operators and shift operators shall be appropriate

9266
note
user-deﬁned literal operator symbol declared with void return type
A user-deﬁned literal operator function was declared as having a void return type.

constexpr void operator""_km(unsigned long long int i);  // note 9266

Supports AUTOSAR17 Rule A13-1-3
Supports AUTOSAR19 Rule A13-1-3

9267
note
user-deﬁned literal operator symbol has side-eﬀects
A user-deﬁned literal operator function was deﬁned as an impure function. Calling this function would produce side-eﬀects. For the deﬁnition of an impure function see the pure semantic deﬁnition.

int global = 0; 
constexpr long operator""_km(unsigned long long int meters) {  // note 9267 
   global += 1; 
   return meters * 1000; 
}

Supports AUTOSAR17 Rule A13-1-3
Supports AUTOSAR19 Rule A13-1-3

9272
note
parameter integer of function symbol has diﬀerent name than overridden function symbol (symbol vs symbol)
This message is similar to 9072 but applied to diﬀerences between overridden functions. In the declaration of a function, the name given to the speciﬁed parameter is diﬀerent from the name given for the same parameter in the declaration of one of the functions being overridden. For example:

struct A { 
   virtual void foo(int width); 
}; 
struct B : A { 
   void foo(int depth); 
};

will yield this message because A::foo uses width as the name of the ﬁrst parameter while the overridden function B::foo uses the name depth.
Supports AUTOSAR17 Rule M8-4-2
Supports AUTOSAR19 Rule M8-4-2
Supports MISRA C++:2008 Rule 8-4-2 - The identiﬁers used for the parameters in a re-declaration of a function shall be identical to those in the declaration.
Supports MISRA C++:2023 Rule 13.3.3 - The parameters in all declarations or overrides of a function shall either be unnamed or have identical names

9273
note
parameter integer of function symbol has type alias name diﬀerence with overridden function symbol (type vs type)
This message is similar to 9073 but applies to diﬀerences between overridden functions. In the declaration of a function, the speciﬁed parameter is declared with a type that, while technically identical, uses a diﬀerent name for the type than was used for the parameter in the declaration of one of the functions that this function overrides. For example:

typedef int INT; 
 
struct A { 
   virtual void foo(int); 
}; 
 
struct B : A { 
   void foo(INT); 
};

will yield this message because A::foo is declared with a ﬁrst parameter of type int while the overridden function B::foo declared the parameter with type INT, a type alias name diﬀerence.

9275
note
class|struct|union|enum identiﬁer 'name' is reused
An identiﬁer reuses the qualiﬁed name of a tag. For example:

struct x {}; 
float x;  // note 9275

Some coding guidelines suggest that tag names should be unique across all ﬁles in a project to avoid programmer confusion. If both uses are identical declarations of a tag, then it should be deﬁned in a shared header ﬁle instead.

Project-wide unique identiﬁers are also enforced by messages 9103 , 9276 , 9277 , 9278 , and 9279 . A more strict enforcement of unique identiﬁers can be applied using the +misra_interpret(any, strict identiﬁer uniqueness) option.
Supports MISRA C 2004 Rule 5.4 - A tag name shall be a unique identiﬁer.
Supports MISRA C 2012 Rule 5.7 - A tag name shall be a unique identiﬁer
Supports MISRA C:2023 Rule 5.7 - A tag name shall be a unique identiﬁer
Supports MISRA C:2025 Rule 5.7
Supports MISRA C++:2008 Rule 2-10-4 - A class, union or enum name (including qualiﬁcation, if any) shall be a unique identiﬁer.

9276
note
typedef identiﬁer 'name' is reused
An identiﬁer reuses the qualiﬁed name of a typedef. For example:

void f() { typedef int x; } 
float x;  // note 9276

Some coding guidelines suggest that typedef names should be unique across all ﬁles in a project to avoid programmer confusion. If both uses are identical typedef declarations, then it should be deﬁned in a shared header ﬁle instead.

Project-wide unique identiﬁers are also enforced by messages 9103 , 9275 , 9277 , 9278 , and 9279 . A more strict enforcement of unique identiﬁers can be applied using the +misra_interpret(any, strict identiﬁer uniqueness) option.
Supports AUTOSAR17 Rule M2-10-3
Supports MISRA C 2004 Rule 5.3 - A typedef name shall be a unique identiﬁer.
Supports MISRA C 2012 Rule 5.6 - A typedef name shall be a unique identiﬁer
Supports MISRA C:2023 Rule 5.6 - A typedef name shall be a unique identiﬁer
Supports MISRA C:2025 Rule 5.6
Supports MISRA C++:2008 Rule 2-10-3 - A typedef name (including qualiﬁcation, if any) shall be a unique identiﬁer.

9277
note
identiﬁer 'name' is used elsewhere to deﬁne a symbol with external linkage
An identiﬁer reuses the name of an object or function deﬁned with external linkage. For example:

int external = 0; 
void f(void) { 
   int external;  // note 9277 
}

Class methods are exempt from receiving this message. Some coding guidelines suggest that identiﬁers that deﬁne an object or function with external linkage should be unique across all name spaces and translation units to avoid confusion.

Project-wide unique identiﬁers are also enforced by messages 9103 , 9275 , 9276 , 9278 , and 9279 . A more strict enforcement of unique identiﬁers can be applied using the +misra_interpret(any, strict identiﬁer uniqueness) option.
Supports MISRA C 2012 Rule 5.8 - Identiﬁers that deﬁne objects or functions with external linkage shall be unique
Supports MISRA C:2023 Rule 5.8 - Identiﬁers that deﬁne objects or functions with external linkage shall be unique
Supports MISRA C:2025 Rule 5.8

9278
note
identiﬁer 'name' is used elsewhere to deﬁne a symbol with internal linkage
An identiﬁer reuses the name of an object or function deﬁned with internal linkage. For example:

static int internal = 0; 
void f(void) { 
   int internal;  // note 9278 
}

Some coding guidelines suggest that identiﬁer names that deﬁne an object or function with internal linkage should be unique across all name spaces and translation units to avoid confusion. An exception is made for inline functions with internal linkage that are deﬁned in a header ﬁle that is included in multiple translation units.

Project-wide unique identiﬁers are also enforced by messages 9103 , 9275 , 9276 , 9277 , and 9279 . A more strict enforcement of unique identiﬁers can be applied using the +misra_interpret(any, strict identiﬁer uniqueness) option.
Supports MISRA C 2012 Rule 5.9 - Identiﬁers that deﬁne objects or functions with internal linkage should be unique
Supports MISRA C:2023 Rule 5.9 - Identiﬁers that deﬁne objects or functions with internal linkage should be unique
Supports MISRA C:2025 Rule 5.9

9279
note
identiﬁer 'name' with static storage is reused within the same namespace 'string'
An identiﬁer of the given name was used elsewhere in the namespace to deﬁne a static function or non-member object with static storage duration. Some coding guidelines advise against such practice due to the potential for programmer confusion.

namespace N { 
   static int var; 
 
   void foo() { 
      int var;  // note 9279 
   } 
} 
 
int var;  // Okay

Project-wide unique identiﬁers are also enforced by messages 9103 , 9275 , 9276 , 9277 , and 9278 . A more strict enforcement of unique identiﬁers can be applied using the +misra_interpret(any, strict identiﬁer uniqueness) option.
Supports AUTOSAR19 Rule A2-10-4

9287
note
cast from pointer to object type (type) to pointer to char type (type)
A cast was performed between a pointer to an object type and a pointer to a character type. The actual pointer types are provided in the message.
Supports MISRA C 2004 Rule 11.4 - A cast should not be performed between a pointer to object type and a diﬀerent pointer to object type.

9288
note
unnamed signed single-bit bitﬁeld
An unnamed signed bit-ﬁeld was declared with a single bit.
Supports MISRA C 2004 Rule 6.5 - Bit ﬁelds of type signed int shall be at least 2 bits long.

9294
note
return type of function symbol has type alias name diﬀerence with overridden function symbol (type vs type)
This message is similar to 9094 but applies to diﬀerences between overridden functions. In a declaration of a function, the return type speciﬁed, while technically identical, uses a diﬀerent type name than was used for the declaration of one of the functions that this function overrides. For example:

typedef int INT; 
 
struct A { 
   virtual int foo(); 
}; 
 
struct B : A { 
   INT foo(); 
};

will yield this message.

9295
note
conversion between object pointer type type and non-integer arithmetic essential type 'essential-type'
This message is issued when a cast is used to convert between a pointer to object type and a non-integer arithmetic MISRA C 2012 essential type. For example:

enum color { RED, GREEN, BLUE }; 
void foo(int *pi) { 
   enum color c = (enum color)pi;  // Note 9295 
}

Supports MISRA C 2012 Rule 11.7 - A cast shall not be performed between pointer to object and a non-integer arithmetic type
Supports MISRA C:2023 Rule 11.7 - A cast shall not be performed between pointer to object and a non-integer arithmetic type
Supports MISRA C:2025 Rule 11.4

9302
note
thrown exception of type type occurs elsewhere in project with hash string
The thrown exception is a duplicate of another exception thrown within the project.

void foo() { 
   throw "Something bad happened"; // note 9302 
} 
 
void bar() { 
   throw "Something bad happened"; // note 9302 
}

See message 9303 for possible duplicate exceptions.
Supports AUTOSAR17 Rule A15-1-3
Supports AUTOSAR19 Rule A15-1-3

9303
note
thrown exception of type type possibly occurs elsewhere in project with hash string
The thrown exception might be a duplicate of another exception thrown within the project.

void foo() { 
   throw MyException("Something bad happened"); // note 9303 
} 
 
void bar() { 
   throw MyException("Something bad happened"); // note 9303 
}

Duplicate exceptions are those having the same type and the same exception message as another. Static analysis might not be able to determine that the exception message would be the same, and can only label these throw expressions as possible duplicates. To manually mark a class as always producing the same exception message given the same constructor arguments, use the pure_exception_constructor semantic. Given that all statically determinable arguments remain consistent, any throw expression whose exception constructor is marked with this semantic shall receive message 9302 for duplicates instead of this message.
Supports AUTOSAR17 Rule A15-1-3
Supports AUTOSAR19 Rule A15-1-3

9401
note
function symbol returns pointer to void
The speciﬁed function returns a pointer to void, which some consider to be unsafe because it can compromise type safety.

9402
note
function symbol parameter integer is void pointer
The speciﬁed function accepts a void pointer as an argument, which some consider to be unsafe because such pointers can compromise type safety.

9403
note
function symbol parameter integer has same unqualiﬁed type (type) as previous parameter
A function has two consecutive parameters of the same (unqualiﬁed) type. Functions that accept many arguments can be diﬃcult to use correctly as the chance of misordered arguments increases as the number of parameters increases. When arguments are of diﬀerent types, misordered arguments are more likely to be detected by the compiler. When consecutive parameters are of the same type, calls to the function that accidentally transpose the arguments are less likely to be noticed.

9404
note
destructor for class symbol should be declared 'noexcept'
Given that destructors should never throw, declaring them as ’noexcept’ is wise as it allows the compiler to ensure this is the case.

9405
note
move constructor for class symbol should be declared 'noexcept'
Move constructors should not throw; declaring them as ’noexcept’ allows the compiler to ensure this is the case.
Supports MISRA C++:2023 Rule 15.0.2 - User-provided copy and move member functions of a class should have appropriate signatures

9406
note
move assignment operator symbol should be declared 'noexcept'
Move assignment functions should not throw; declaring them as ’noexcept’ allows the compiler to ensure this is the case.
Supports MISRA C++:2023 Rule 15.0.2 - User-provided copy and move member functions of a class should have appropriate signatures

9407
note
copy assignment operator symbol should not be virtual
A copy assignment operator was declared as virtual; this is rarely the right thing to do. Virtual move assignment operators are reported by 9410 . Virtual non-copy, non-move assignment operators are reported by 9438 .
Supports AUTOSAR17 Rule A10-3-5
Supports AUTOSAR19 Rule A10-3-5
Supports MISRA C++:2023 Rule 15.0.2 - User-provided copy and move member functions of a class should have appropriate signatures

9408
note
copy assignment operator symbol should take a const reference type
A copy assignment operator should take a const reference argument.
Supports MISRA C++:2023 Rule 15.0.2 - User-provided copy and move member functions of a class should have appropriate signatures

9409
note
copy assignment operator symbol should return a non-const lvalue-reference type
A copy assignment operator should return a non-const lvalue-reference type.
Supports MISRA C++:2023 Rule 15.0.2 - User-provided copy and move member functions of a class should have appropriate signatures

9410
note
move assignment operator symbol should not be virtual
A move assignment operator was declared as virtual; this is rarely the right thing to do. Virtual copy assignment operators are reported by 9407 . Virtual non-copy, non-move assignment operators are reported by 9438 .
Supports AUTOSAR17 Rule A10-3-5
Supports AUTOSAR19 Rule A10-3-5
Supports MISRA C++:2023 Rule 15.0.2 - User-provided copy and move member functions of a class should have appropriate signatures

9411
note
move assignment operator symbol should take a non-const reference type
A move assignment operator was declared whose argument is not a non-const reference.
Supports MISRA C++:2023 Rule 15.0.2 - User-provided copy and move member functions of a class should have appropriate signatures

9412
note
move assignment operator symbol should return a non-const lvalue-reference type
A move assignment operator was declared that doesn’t return a non-const lvalue-reference type.
Supports MISRA C++:2023 Rule 15.0.2 - User-provided copy and move member functions of a class should have appropriate signatures

9413
note
class symbol contains data members of diﬀering access levels
A class contains data members declared with diﬀerent access levels.
Supports MISRA C++:2023 Rule 14.1.1 - Non-static data members should be either all private or all public

9414
note
'typeid' used on expression with side eﬀect
If the operand of the typeid operator is an expression, it is not usually evaluated. Using typeid with an expression that would have side eﬀects if it were evaluated could result in confusion about whether the apparent side-eﬀects will actually take place.
Supports AUTOSAR17 Rule A5-3-1
Supports AUTOSAR19 Rule A5-3-1

9415
note
'auto' variable symbol initialized using 'string' list initialization
Initializing an auto variable using list initialization can result in unexpected and compiler-dependent results. Additionally, the rules governing the type deduced when using list initialization with auto variables changed in C++17 which can result in code that has diﬀerent meaning depending on the target language of the compiler. For example:

   auto j1{1};    // direct list initialization 
                // j1 is std::initializer_list<int> in C++11 and int in C++17 
 
   auto j2 = {1};  // copy list initialization 
                // j2 is always std::initializer_list<int> 
 
   auto j3 = 1;   // copy initialization - NOT list initialization 
                // j3 is always int

This message will be issued for the initialization of j1 and j2. Avoiding list initialization for auto variables can prevent unintended results. The string parameter is either ’direct’ or ’copy’ indicating the type of list initialization employed (copy list initialization uses an equal sign, direct list initialization does not).
Supports AUTOSAR17 Rule A8-5-3
Supports AUTOSAR19 Rule A8-5-3

9416
note
typedef used to deﬁne name symbol
A typedef was used to deﬁne a type alias instead of a using alias.
Supports AUTOSAR17 Rule A7-1-6
Supports AUTOSAR19 Rule A7-1-6

9417
note
data member symbol has protected access level
The speciﬁed data member of a class has an access level of protected. Some authors suggest against using protected data members.
Supports MISRA C++:2023 Rule 14.1.1 - Non-static data members should be either all private or all public

9418
note
enum symbol does not have an explicitly speciﬁed underlying type
Since C++11 it is possible to explicitly specify an underlying type for enums and enum classes. This message is issued for enums that do not explicitly specify an underlying type in their deﬁnition. This message is not issued in C or C++03 modes.
Supports AUTOSAR17 Rule A7-2-2
Supports AUTOSAR19 Rule A7-2-2
Supports MISRA C++:2023 Rule 10.2.1 - An enumeration shall be deﬁned with an explicit underlying type

9419
note
enum symbol is not a scoped enumeration
Scoped enumerations (those using enum class or enum struct) were introduced in C++11 and limit the scope of the enumeration constants to the enumeration. This message is issued for unscoped enums. This message is not issued in C or C++03 modes.
Supports AUTOSAR17 Rule A7-2-3
Supports AUTOSAR19 Rule A7-2-3
Supports MISRA C++:2023 Rule 10.2.2 - Unscoped enumerations should not be declared

9420
note
bitﬁeld symbol does not have unsigned integer or explicitly unsigned enumeration type
This message is issued when a bitﬁeld is declared with a type that is not an implementation-independent unsigned integral type. In particular, the message is issued for bitﬁelds with plain char, plain int, or wchar_t types or types that are implicitly or explicitly signed such as short and signed short. For bitﬁelds of enumeration type, if the underlying type of the enumeration is explicitly speciﬁed as an unsigned type, the message is suppressed. As it is only possible to specify an explicit underlying type for enumerations since C++11, the message will be issued for all bitﬁelds of enum type in C or C++03 modes.
Supports AUTOSAR17 Rule A9-6-1

9421
note
virtual function symbol overrides function symbol and is not marked with 'override' or 'ﬁnal'
A virtual function that overrides a base class function was not declared with at least one of override or final. This message is only emitted for C++11 and higher. See also 1915 which is issued when an overriding function is not speciﬁed with override, even if final is speciﬁed.
Supports AUTOSAR17 Rule A10-3-2
Supports AUTOSAR19 Rule A10-3-2
Supports MISRA C++:2023 Rule 13.3.1 - User-declared member functions shall use the virtual, override and ﬁnal speciﬁers appropriately

9422
note
virtual function symbol should specify exactly one of 'virtual', 'override', or 'ﬁnal'
A virtual function was declared without specifying exactly one of virtual, override, or final. Some authors suggest that virtual should be speciﬁed in the base class and that overriding functions should be speciﬁed with either override or final and without a redundant virtual speciﬁer. This message is only issued for C++11 and higher.
Supports AUTOSAR17 Rule A10-3-1
Supports AUTOSAR19 Rule A10-3-1
Supports MISRA C++:2023 Rule 13.3.1 - User-declared member functions shall use the virtual, override and ﬁnal speciﬁers appropriately

9423
note
non-basic character used in identiﬁer string
This message is issued when a non-basic source character is used in an identiﬁer.
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

9424
note
parameter list omitted from lambda expression
The parentheses denoting an empty parameter list were absent from a lambda expression. C++ allows a lambda expression to be written without an explicit parameter list if the lambda takes no arguments, does not specify a trailing return type or an exception speciﬁcation, and is not speciﬁed as constexpr or mutable. Including an empty parameter list provides visual consistency with other callable objects.
Supports AUTOSAR17 Rule A5-1-3
Supports AUTOSAR19 Rule A5-1-3

9426
note
lambda used as operand to decltype or typeid
An expression of lambda type was used as an operand to the decltype or typeid operators. For example:

void f() { 
   auto lambda = []() -> int { return 2; }; 
   using lambda_t = decltype(lambda);       // note 9426 
}

Since each lambda has a distinct type, this usage is suspicious, for example, the typeid of two identically deﬁned lambdas will be diﬀerent.
Supports AUTOSAR17 Rule A5-1-7
Supports AUTOSAR19 Rule A5-1-7

9428
note
object declared with the deﬁnition of class|struct|union|enum symbol
This message is issued whenever an enumeration, union, class, or structure object is declared with the deﬁnition of its type. Some coding guidelines prohibit the deﬁnition of a class, structure, union, or enumeration type with the declaration of a variable in the same statement. For example:

enum class E1 { C11, C12, } e1;  // 9428 
enum class E2 { C21, C22, };     // Okay 
E2 e2; 
struct S *s;                  // Okay - Not a definition of S

Supports AUTOSAR19 Rule A7-1-9

9432
note
class symbol has multiple non-interface bases
An interface is a class where 1) all non-static member functions (if any) are public, virtual, and pure, and 2) all data members (if any) are public, static (or thread_local), and constexpr (or const in C++ modes prior to C++11). This message is issued when a class inherits from more than one non-interface class. The list of non-interface bases are provided in a supplemental message.
Supports AUTOSAR17 Rule A10-1-1
Supports AUTOSAR19 Rule A10-1-1

9433
note
literal operator function symbol declared
This message is issued whenever a literal operator function declaration is encountered. Literal operators introduce user-deﬁned literal suﬃxes that can be applied to certain types of literals. See also message 9434 which is issued when a literal operator is invoked by a user-deﬁned literal.
Supports AUTOSAR17 Rule A13-1-1

9434
note
user-deﬁned literal with suﬃx string used
This message is issued when a user-deﬁned literal is encountered. This message is parameterized by the suﬃx used and can be suppressed for individual suﬃxes using -estring . See also message 9433 which is issued for the declaration of literal operator functions which introduce user-deﬁned suﬃxes.
Supports AUTOSAR17 Rule A13-1-1

9435
note
string symbol declared as friend in class symbol
This message is issued when a friend declaration is encountered. The string parameter is either symbol or type to indicate the kind of entity declared as a friend. The ﬁrst symbol parameter is the entity declared as a friend unless the entity is a type in which case the parameter is actually a type parameter. The last symbol is the class in which the friend declaration appeared. Some authors suggest that friend declarations reduce encapsulation and should be avoided.
Supports AUTOSAR17 Rule A11-3-1
Supports AUTOSAR19 Rule A11-3-1

9436
note
symbol symbol has array type type
A symbol was declared with array type or reference to array type in a C++ module. For example:

int array[10];  // note 9436

Because arrays are implicitly convertible to pointers and don’t maintain size information across such conversions, arrays are the subject of various programming errors. Some authors suggest replacing arrays with other container types such as std::array or std::vector.
Supports AUTOSAR17 Rule A18-1-1
Supports AUTOSAR19 Rule A18-1-1
Supports MISRA C++:2023 Rule 11.3.1 - Variables of array type should not be declared

9437
note
non-POD class symbol deﬁned with 'struct' keyword
This message is issued when a non-POD class is deﬁned using the struct keyword. Some authors suggest that non-POD types should be deﬁned using the class keyword which forces private default access control.

For structs that use non-public data members see message 9242 . For structs that use static data members see message 9243 . For structs that use methods see message 9244 . For structs that inherit from other classes see message 9245 . For classes that inherit from structs see message 9246 .
Supports AUTOSAR17 Rule A11-0-1
Supports AUTOSAR19 Rule A11-0-1

9438
note
non-copy, non-move assignment operator symbol should not be virtual
A non-copy, non-move assignment operator was declared as virtual; this is rarely the right thing to do. Virtual copy assignment operators are reported by 9407 . Virtual move assignment operators are reported by 9410 .
Supports AUTOSAR17 Rule A10-3-5
Supports AUTOSAR19 Rule A10-3-5

9439
note
hexadecimal integral|ﬂoating literal 'string' should be upper case
This message is issued whenever a hexadecimal ﬂoating or integer literal with lower case digits (a-f) is encountered.
Supports AUTOSAR19 Rule A2-13-5

9440
note
digit sequence separators instring binary|octal|decimal|hexadecimal integer|ﬂoating literal 'string' should be every integer digits
This message is issued whenever the digit sequence separators (’) in an integral or ﬂoating literal do not occur every Nth digit, where N is: 2 for hexadecimal, 3 for decimal and octal, and 4 for binary.
Supports AUTOSAR17 Rule A13-6-1
Supports AUTOSAR19 Rule A13-6-1

9441
note
non-ﬁnal class symbol has a public non-virtual destructor
This message is issued whenever there is a public non-virtual destructor in an essentially non-ﬁnal class. A class is essentially non-ﬁnal if neither it nor its destructor is marked final.
Supports AUTOSAR17 Rule A12-4-2
Supports AUTOSAR19 Rule A12-4-2

9442
note
nested lambda expression
This message is issued whenever a lambda expression is nested in another lambda expression. For example:

void f() { 
   auto f1 = []() {     // okay 
      auto f2 = []() {};  // 9442 
   }; 
}

Supports AUTOSAR17 Rule A5-1-8
Supports AUTOSAR19 Rule A5-1-8

9443
note
universal-character-name used in identiﬁer string
This message is issued when a Universal Character Name (UCN) appears in an identiﬁer. A UCN starts with \u followed by 4 hex digits or \U followed by 8 hex digits. Using UCNs in identiﬁers can make the identiﬁers diﬃcult to read and diﬀerentiate from other identiﬁers.
Supports AUTOSAR19 Rule A2-13-6
Supports MISRA C 2012 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2023 Rule 1.3 - There shall be no occurrence of undeﬁned or critical unspeciﬁed behaviour
Supports MISRA C:2025 Rule 1.3

9444
note
user declared comparison operator symbol is a member function
This message is issued whenever a comparison operator (==, !=, <, <=, >=, >) is a member function. Some coding guidelines require comparison operators to be symetric with respect to their operands. For example:

struct S { 
   bool operator==(const S& o) const noexcept;              // 9444 
   friend bool operator!=(const S& l, const S& r) noexcept;   // Okay 
};

Supports AUTOSAR19 Rule A13-5-5

9445
note
user declared comparison operator symbol is not noexcept
This message is issued whenever a comparison operator (==, !=, <, <=, >=, >) is not noexcept. Some coding guidelines require comparison operators to be noexcept. For example:

struct S { 
   friend bool operator==(const S& l, const S& r);           // 9445 
   friend bool operator!=(const S& l, const S& r) noexcept;   // Okay 
};

Supports AUTOSAR19 Rule A13-5-5

9446
note
user declared comparison operator symbol does not have identical parameter types
This message is issued whenever a comparison operator (==, !=, <, <=, >=, >) has diﬀerent parameter types. Some coding guidelines require comparison operators to be symetric with respect to their operands. For example:

struct S { 
   friend bool operator==(const S& l, const S* r) noexcept;   // 9446 
   friend bool operator!=(const S& l, const S& r) noexcept;   // Okay 
};

Supports AUTOSAR19 Rule A13-5-5

9447
info
the return type of non-member|member assignment operator symbol should be type
This message is issued whenever the return type of a user deﬁned assignment operator is not:

a reference to the class for member functions;
a reference to the ﬁrst parameter for non-member functions.

For example:

class C1 { 
public: 
   // ... 
   C1& operator+=(const C1& rhs) &;     // okay 
   C1 operator-=(const C1& rhs) &;      // 9447 
}; 
 
class C2 { /* ... */ }; 
 
C2& operator+=(C2& lhs, const C2& rhs);   // okay 
C2 operator-=(C2& lhs, const C2& rhs);    // 9447

Supports AUTOSAR17 Rule A13-2-1
Supports AUTOSAR19 Rule A13-2-1

9448
info
the return value of non-member|member assignment operator symbol should be string
This message is issued whenever the return value of a user deﬁned assignment operator is not:

’*this’ for member functions;
the ﬁrst parameter for non-member functions.

For example:

class C3 { 
public: 
   // ... 
   C3& operator+=(const C3& rhs) & { 
      return *this;                // okay 
   } 
 
   C3& operator-=(C3& rhs) & { 
      return rhs;                 // 9448 
   } 
}; 
 
class C4 { /* ... */ }; 
 
C4& operator+=(C4& lhs, const C4& rhs) { 
   return lhs;                     // okay 
} 
 
C4& operator-=(C4& lhs, C4& rhs) { 
   return rhs;                     // 9448 
}

Supports AUTOSAR17 Rule A13-2-1
Supports AUTOSAR19 Rule A13-2-1

9449
note
inlined member function symbol is not marked as inline
This message is issued whenever a non-deleted, non-defaulted, inlined member function deﬁnition is not marked with the inline, constexpr, or consteval keywords and it is not a function template or a member function of a class template. For example:

class A { 
public: 
   void f1() {}                    // 9449 
   inline void f2() {}              // okay - marked inline 
   A() = default;                  // okay - marked default 
   ~A() = delete;                  // okay - marked delete 
   constexpr int f3() { return 2; }   // okay - marked constexpr 
   consteval int f4() { return 3; }   // okay - marked consteval 
   template <typename T> 
   void f5(const T& t) {}            // okay - function template 
}; 
 
template <typename T> 
class B { 
public: 
   explicit B(const T& x) : t(x) {}   // okay - member of class template 
private: 
   T t; 
};

Supports AUTOSAR19 Rule A3-1-5

9453
note
variable symbol is not directly initialized with braces
A variable initializer uses initialization other than direct-list-initialization. The message is not emitted for class types which have both a non-deleted std::initializer_list constructor and non-deleted non-default constructor, since the non-deleted non-default constructor may not be able to be called using direct-list-initialization. Using direct-initialization with parentheses is allowed in this case.

int a{1}; 
int b = 1;  // note 9453

This message is not issued for variables of dependent types in templates that use direct-initialization. Future users of the template may instantiate using types that require the use of direct-initialization with parentheses to access certain constructors.

This message will not be emitted for C modules.

See message 9454 (member initializer does not use braces) for dealing with member initializers.
Supports AUTOSAR17 Rule A8-5-2
Supports AUTOSAR19 Rule A8-5-2

9454
note
member initializer for symbol is not initialized with braces
A member initializer in a member initializer list uses initialization other than direct-list-initialization. The message is not emitted for class types which have both a non-deleted std::initializer_list constructor and non-deleted non-default constructor, since the non-deleted non-default constructor may not be able to be called using direct-list-initialization. Using direct-initialization with parentheses is allowed in this case.

class C { 
   int x; 
public: 
   C() : x{0} {} 
   C(int i) : x(i) {}  // note 9454 
};

This message is not issued for member intializers of dependent types in templates that use direct-initialization. Future users of the template may instantiate using types that require the use of direct-initialization with parentheses to access certain constructors.

See message 9453 (variable initialization does not use braces) for dealing with variable initializers.

9456
note
do statement used outside of statement-like macro
This message reports any use of a do statement with the exception that a do statement with a condition of 0 or false may be used in the deﬁnition of a macro.
Supports AUTOSAR19 Rule A6-5-3

9470
note
string symbol is not noexcept
This message reports potentially-throwing user-provided functions that should not throw exceptions. The functions that should not throw exceptions include destructors, deallocation functions, move constructors, move assignment operators and swap functions. The C++ standard deﬁnes that destructors (if none of its dependent destructors are potentially-throwing) and deallocation functions are non-throwing by default. A noexcept exception speciﬁer should be added to the functions referenced by this message.

This message does not report generic move constructors, generic move assignment operators, and generic swap functions that have noexcept speciﬁcations which depend on type properties of the template parameters but will report instantiations that are potentially-throwing. On the other hand, generic destructors and generic deallocation functions that have noexcept speciﬁcations which depend on type properties of the template parameters will only be reported within the template deﬁnition because they should never throw.
Supports AUTOSAR17 Rule A15-5-1
Supports AUTOSAR19 Rule A15-5-1

9501
note
preprocessing directive in call to function symbol
A preprocessing directive appeared within the call to a function, for example:

void init_buffer(void *buffer) { 
   memset(buffer, 0, 
#ifdef LARGE_BUFFER 
   1024 
#else 
   128 
#endif 
   ); 
}

The problem is that if memset is implemented as a macro, the presence of the embedded preprocessor directives would invoke undeﬁned behavior. PC-lint Plus issues message 436 when a preprocessor directive appears inside a macro invocation but message 9501 can be used to warn about directives in function calls that may be implemented as macros in other conﬁgurations or when compiled on other platforms.

One alternative is to move the directives outside the call, e.g.:

void init_buffer(void *buffer) { 
   const unsigned buf_size = 
#ifdef LARGE_BUFFER 
   1024 
#else 
   128 
#endif 
   ; 
   memset(buffer, 0, buf_size); 
}

This message isn’t issued if the function name is surrounded by parenthesis which suppresses the invocation of a potential macro by the same name. This message is parameterized on the function being called and can be enabled for speciﬁc functions using either +esym or +ecall .
Supports CERT C PRE32-C - Do not use preprocessor directives in invocations of function-like macros

9502
note
multi-statement macro 'name' is not enclosed in monocarpic do-while loop
A macro deﬁnition appeared to contain multiple statements but was not enclosed in a mono-carpic do/while loop. A macro is considered to contain multiple statements if the replacement text contains one or more semi-colons. A mono-carpic do/while loop is one that will be executed exactly once. PC-lint Plus is speciﬁcally expecting a loop of the following form:

#define M(x) do { ... } while (0)

where 0 may be replaced by any integer literal with a zero value (0u, 0x0, etc.), the false keyword or a keyword that has been assigned the same meaning as false with the -rw_asgn option, or an identiﬁer whose name is false, ignoring case.

A macro that expands to multiple statements may result in unintentional interpretation during expansion. For example:

#define ADJUST(a, b) a = (b); a++; b = 0

would not work as intended if used as:

void foo(int a, int b) { 
   if (a >= b) 
      ADJUST(a, b); 
}

which would expand to:

void foo(int a, int b) { 
   if (a >= b) 
      a = (b); a++; b = 0; 
}

where the last two statements would be unconditionally executed as they are not part of the if statement. Simply wrapping the macro deﬁnition in braces is not always suﬃcient:

#define ADJUST(a, b) { a = (b); a++; b = 0; }

as this will prevent the macro from being usable in certain contexts, e.g.:

void foo(int a, int b) { 
   if (a >= b) 
      ADJUST(a, b); 
   else 
      ADJUST(b, a); 
}

will result in a compile error as the else is not attached to the if statement because of the semi-colon. Wrapping the replacement text in a do/while (0) loop addresses all of the related issues:

#define ADJUST(a, b) do { a = (b); a++; b = 0; } while (0)

Supports CERT C PRE10-C - Wrap multistatement macros in a do-while loop

9503
note
declaration of symbol speciﬁes an alignment of integer diﬀerently from another declaration that derives an equivalent alignment on a diﬀerent basis (string vs string)
The resulting alignment of an externally visible object is consistent with other declarations of the object, but is not derived the same way. If the conﬁguration or target architecture changes, there is a risk of introducing an inconsistency, resulting in undeﬁned behavior. For example, if the size of float is 4:

extern _Alignas(4)    int a; // Note 9503 
extern _Alignas(float) int a; // Note 9503

The related message 2502 , will report when an externally visible object has a resulting alignment that conﬂicts with other declarations.
Supports MISRA C 2012 AMD3 Rule 8.15 - All declarations of an object with an explicit alignment speciﬁcation shall specify the same alignment
Supports MISRA C:2023 Rule 8.15 - All declarations of an object with an explicit alignment speciﬁcation shall specify the same alignment
Supports MISRA C:2025 Rule 8.15

9504
note
argument with essential type 'string' supplied to type-generic macro 'macro' resulting in call to function symbol should have an string type
The operand argument passed to a type-generic macro has an inappropriate essential type. The operand argument must have an essentially signed, essentially unsigned, or essentially (real or complex) ﬂoating type. Type-generic macros from tgmath.h can support real types, complex types, or both. Passing a complex type to a macro expecting a real type results in undeﬁned behavior. Likewise, arguments of non-arithmetic types are not convertible to any of the corresponding real types deﬁned for the macros and attempting to use them is also undeﬁned behavior. This message overlaps with 2504 . In addition to the undeﬁned behavior that message reports, this includes violations of the MISRA C 2012 essential type system.

float i; 
char c; 
sqrt(f); // OK, essentially floating real type 
exp(c);  // Note 9504, essentially character type

Supports MISRA C 2012 AMD3 Rule 21.22 - All operand arguments to any type-generic macros declared in <tgmath.h> shall have an appropriate essential type
Supports MISRA C:2023 Rule 21.22 - All operand arguments to any type-generic macros declared in <tgmath.h> shall have an appropriate essential type
Supports MISRA C:2025 Rule 21.22

9508
note
global/local variable symbol has static/thread storage duration and is implicitly zero-initialized
A variable with static or thread storage duration, such as a global variable, function scope static variable, or static class data member has been found to have implicit zero-initialization (C++) or implicit default initialization (C). A static class data member is considered a "global" variable for the purposes of the ﬁrst message parameter.

int global; // note 9508 
 
int main() { 
   return global; 
}

Message 3708 is available to detect when a static or thread storage duration variables has an initializer that is not a constant-initializer.
Supports AUTOSAR19 Rule A3-3-2

9514
note
suﬃx 'string' of user-deﬁned literal operator symbol contains non-letter character 'string' after underscore
User deﬁned literal suﬃx identiﬁers that starts with a single underscore but are followed by a non-letter characters may be confusing to read. This message will not be issued for any declarations in the std namespace. A character is considered to be letter if it is considered an alphabetic character in the current system locale.

float operator ""_n0(const char*);  // note 9514

Note: This message considers Unicode codepoints outside of the Basic Latin block to not be letters. A double underscore will at the start of the identiﬁer will not be diagnosed by this message, but rather message 3714 (user deﬁned literal suﬃx doesn’t start with single underscore) as this is not allowed by the C++ standard.
Supports AUTOSAR17 Rule A13-1-2
Supports AUTOSAR19 Rule A13-1-2

9901
note
return value 'string' for call to function symbol updated to 'string' via return semantic 'string'
This message is emitted when a return semantic adds or updates value tracking information for a return value of a function call either because the semantic contains more speciﬁc information than was gleaned from walking the body of the called function or because the fso ﬂag was set.

9902
note
return value 'string' for call to function symbol not updated by return semantic 'string' which adds no new information
This message is emitted when a return semantic is not applied to a function call because the semantic does not provide any information that was not already known from walking the call.

9903
note
essential-type-preview
This message shows the step-by-step evaluation of how an expression’s MISRA C 2012 essential type is calculated. See the f12 ﬂag for details.

9904
note
hook event: 'string'
This message is emitted every time a hookable event is reached in the AST walking phase.

9905
note
value tracking debug assertion not known to be unequivocally true
(Debug) When an explicit cast is seen to a type deﬁned by a typedef named __vt_assert, conventionally a typedef for void, this message will be issued during Value Tracking if it does not appear to be guaranteed that the subexpression is a non-zero integral value. This may occur multiple times for the same expression during speciﬁc walks.

9906
note
value tracking debug value: string
(Debug) When an explicit cast is seen to a type deﬁned by a typedef named __vt_alert, conventionally a typedef for void, this message will be issued during Value Tracking parameterized by the value of the subexpression as it would be displayed in a Value Tracking message. This may occur multiple times for the same expression during speciﬁc walks.

9907
note
metric report debug value
(Debug) If the report format debug_msg is speciﬁed using the format sub-option of the +metric_report option then message 9907 will be emitted with the text of each individual row that would have been emitted with format=csv.

[next] [prev] [contents]

%C	wchar_t	XSI/MS extension, equivalent to %lc
%D	int	Apple extension, synonym for %d
%O	unsigned int	Apple extension, synonym for %o
%S	wchar_t *	XSI/MS extension, equivalent to %ls
%U	unsigned int	Apple extension, synonym for %u
%Z	ANSI_STRING / UNICODE_STRING	MS extension
%m	none	Glibc extension, prints output of strerror(errno)