Many resources are needed to download a project. Please understand that we have to compensate our server costs. Thank you in advance. Project price only 1 $
You can buy this project and download/modify it how often you want.
<?xml version="1.0" encoding="UTF-8"?>
<rules>
<rule>
<key>C4001</key>
<configkey>C4001</configkey>
<priority>CRITICAL</priority>
<name>warning C4001: nonstandard extension 'single line comment' was used</name>
<description>
Single-line comments are standard in C++ and nonstandard in
C. Under strict ANSI compatibility (/Za), C files that contain
single-line comments, generate C4001 due to the usage of a nonstandard
extension. Since single-line comments are standard in C++, C files
containing single-line comments do not produce C4001 when compiling
with Microsoft extensions (/Ze).
</description>
</rule>
<rule>
<key>C4002</key>
<configkey>C4002</configkey>
<priority>CRITICAL</priority>
<name>warning C4002: too many actual parameters for macro 'identifier'</name>
<description>
The number of actual parameters in the macro exceeds the number
of formal parameters in the macro definition. The preprocessor
collects the extra parameters but ignores them during macro expansion.
</description>
</rule>
<rule>
<key>C4003</key>
<configkey>C4003</configkey>
<priority>CRITICAL</priority>
<name>warning C4003: not enough actual parameters for macro 'identifier'</name>
<description>
The number of formal parameters in the macro definition exceeds
the number of actual parameters in the macro. Macro expansion
substitutes empty text for the missing parameters.
</description>
</rule>
<rule>
<key>C4005</key>
<configkey>C4005</configkey>
<priority>CRITICAL</priority>
<name>warning C4005: 'identifier' : macro redefinition</name>
<description>
The macro identifier is defined twice. The compiler uses the
second macro definition.
</description>
</rule>
<rule>
<key>C4007</key>
<configkey>C4007</configkey>
<priority>CRITICAL</priority>
<name>warning C4007: 'function' : must be 'attribute'</name>
<description>
A required attribute for a function is not explicitly
stated. For example, the function main must have the __cdecl
attribute. The compiler forces the attribute.
</description>
</rule>
<rule>
<key>C4010</key>
<configkey>C4010</configkey>
<priority>CRITICAL</priority>
<name>warning C4010: single-line comment contains line-continuation character</name>
<description>
A single-line comment, which is introduced by //, contains a
backslash (\) that serves as a line-continuation character. The
compiler considers the next line to be a continuation and treats it as
a comment.
</description>
</rule>
<rule>
<key>C4013</key>
<configkey>C4013</configkey>
<priority>CRITICAL</priority>
<name>warning C4013: 'function' undefined; assuming extern returning int</name>
<description>
The compiler encountered a call to an undefined function.
</description>
</rule>
<rule>
<key>C4015</key>
<configkey>C4015</configkey>
<priority>CRITICAL</priority>
<name>warning C4015: 'identifier' : type of bit field must be integral</name>
<description>
The bit field is not declared as an integer type. The compiler
assumes the base type of the bit field to be unsigned. Bit fields must
be declared as unsigned integer types.
</description>
</rule>
<rule>
<key>C4018</key>
<configkey>C4018</configkey>
<priority>CRITICAL</priority>
<name>warning C4018: 'expression' : signed/unsigned mismatch</name>
<description>
Comparing a signed and unsigned number required the compiler to
convert the signed value to unsigned.
</description>
</rule>
<rule>
<key>C4020</key>
<configkey>C4020</configkey>
<priority>CRITICAL</priority>
<name>warning C4020: 'function' : too many actual parameters</name>
<description>
The number of actual parameters in a function call exceeds the
number of formal parameters in the function prototype or
definition. The compiler passes the extra actual parameters according
to the calling convention of the function.
</description>
</rule>
<rule>
<key>C4022</key>
<configkey>C4022</configkey>
<priority>CRITICAL</priority>
<name>warning C4022: 'function' : pointer mismatch for actual parameter 'number'
</name>
<description>
The pointer type of the actual parameter differs from the
pointer type of the corresponding formal parameter. The actual
parameter is passed without change.
</description>
</rule>
<rule>
<key>C4024</key>
<configkey>C4024</configkey>
<priority>CRITICAL</priority>
<name>warning C4024: 'function' : different types for formal and actual parameter
'number'</name>
<description>
Corresponding formal and actual parameters have different
types. The compiler passes the actual parameter without change. The
receiving function converts the parameter type to the type expected.
</description>
</rule>
<rule>
<key>C4028</key>
<configkey>C4028</configkey>
<priority>CRITICAL</priority>
<name>warning C4028: formal parameter 'number' different from declaration</name>
<description>
The type of the formal parameter does not agree with the
corresponding parameter in the declaration. The type in the original
declaration is used.
</description>
</rule>
<rule>
<key>C4029</key>
<configkey>C4029</configkey>
<priority>CRITICAL</priority>
<name>warning C4029: declared formal parameter list different from definition</name>
<description>
Formal parameter types in the function declaration do not agree
with those in the function definition. The compiler uses the parameter
list from the definition.
</description>
</rule>
<rule>
<key>C4031</key>
<configkey>C4031</configkey>
<priority>CRITICAL</priority>
<name>warning C4031: second formal parameter list longer than the first list</name>
<description>
A function is redeclared with different formal parameters. The
compiler uses the formal parameters given in the first declaration.
</description>
</rule>
<rule>
<key>C4032</key>
<configkey>C4032</configkey>
<priority>CRITICAL</priority>
<name>warning C4032: formal parameter 'number' has different type when promoted
</name>
<description>
The parameter type is not compatible, through default
promotions, with the type in a previous declaration
</description>
</rule>
<rule>
<key>C4034</key>
<configkey>C4034</configkey>
<priority>CRITICAL</priority>
<name>warning C4034: sizeof returns 0</name>
<description>
The sizeof operator is applied to an operand of size zero
(an empty structure, union, class, or enumerated type, or type void).
</description>
</rule>
<rule>
<key>C4042</key>
<configkey>C4042</configkey>
<priority>CRITICAL</priority>
<name>warning C4042: 'identifier' : has bad storage class</name>
<description>
The specified storage class cannot be used with this
identifier in this context. The compiler uses the default storage
class instead:
- extern , if identifier is a function.
- auto, if identifier is a formal parameter or local variable.
- No storage class, if identifier is a global variable.
</description>
</rule>
<rule>
<key>C4047</key>
<configkey>C4047</configkey>
<priority>CRITICAL</priority>
<name>warning C4047: 'operator' : 'identifier1' differs in levels of indirection from
'identifier2' </name>
<description>
A pointer can point to a variable (one level of
indirection), to another pointer that points to a variable (two
levels of indirection), and so on.
</description>
</rule>
<rule>
<key>C4048</key>
<configkey>C4048</configkey>
<priority>CRITICAL</priority>
<name>warning C4048: different declared array subscripts : 'identifier1' and
'identifier2'</name>
<description>
An expression involves pointers to arrays of different
size. The pointers are used without conversion.
</description>
</rule>
<rule>
<key>C4049</key>
<configkey>C4049</configkey>
<priority>CRITICAL</priority>
<name>warning C4049: compiler limit : terminating line number emission</name>
<description>
The file contains more than 16,777,215 source lines. The
compiler stops numbering at 16,777,215.
For code after line 16,777,215:
- The image will contain no debug information for line numbers.
- Some diagnostics may be reported with incorrect line numbers.
- .asm listings (/FAs) may have incorrect line numbers.
</description>
</rule>
<rule>
<key>C4056</key>
<configkey>C4056</configkey>
<priority>CRITICAL</priority>
<name>warning C4056: overflow in floating point constant arithmetic</name>
<description>
Floating-point constant arithmetic generates a result
that exceeds the maximum allowable value.
</description>
</rule>
<rule>
<key>C4061</key>
<configkey>C4061</configkey>
<priority>CRITICAL</priority>
<name>warning C4061: enumerator 'identifier' in switch of enum 'enumeration' is not
explicitly handled by a case label</name>
<description>
The enumerate has no associated handler in a switch
statement.
</description>
</rule>
<rule>
<key>C4062</key>
<configkey>C4062</configkey>
<priority>CRITICAL</priority>
<name>warning C4062: enumerator 'identifier' in switch of enum 'enumeration' is not
handled</name>
<description>
The enumerate has no associated handler in a switch
statement, and there is no default label.
</description>
</rule>
<rule>
<key>C4067</key>
<configkey>C4067</configkey>
<priority>CRITICAL</priority>
<name>warning C4067: unexpected tokens following preprocessor directive - expected a
newline</name>
<description>
The compiler found and ignored extra characters following
a preprocessor directive. This warning appears only under ANSI
compatibility (/Za).
</description>
</rule>
<rule>
<key>C4073</key>
<configkey>C4073</configkey>
<priority>CRITICAL</priority>
<name>warning C4073: initializers put in library initialization area</name>
<description>
Only third-party library developers should use the
library initialization area, which is specified by '#pragma
init_seg'.
</description>
</rule>
<rule>
<key>C4074</key>
<configkey>C4074</configkey>
<priority>CRITICAL</priority>
<name>warning C4074: initializers put in compiler reserved initialization area</name>
<description>
The compiler initialization area, which is specified by
'#pragma init_seg', is reserved by Microsoft. Code in this area may
be executed before initialization of the C run-time library.
</description>
</rule>
<rule>
<key>C4079</key>
<configkey>C4079</configkey>
<priority>CRITICAL</priority>
<name>warning C4079: unexpected token 'token'</name>
<description>
An unexpected separator token occurs in a pragma argument
list. The remainder of the pragma was ignored.
</description>
</rule>
<rule>
<key>C4083</key>
<configkey>C4083</configkey>
<priority>CRITICAL</priority>
<name>warning C4083: expected 'token'; found identifier 'identifier'</name>
<description>
An identifier occurs in the wrong place in a #pragma
statement.
</description>
</rule>
<rule>
<key>C4088</key>
<configkey>C4088</configkey>
<priority>CRITICAL</priority>
<name>warning C4088: 'function' : pointer mismatch in actual parameter 'number',
formal parameter 'number'</name>
<description>
The corresponding formal and actual parameters have a
different level of indirection. The actual parameter is passed
without change. The called function interprets its value as a
pointer.
</description>
</rule>
<rule>
<key>C4089</key>
<configkey>C4089</configkey>
<priority>CRITICAL</priority>
<name>warning C4089: 'function' : different types in actual parameter 'number',
formal parameter 'number'</name>
<description>
The corresponding formal and actual parameters have
different types. The actual parameter is passed without change. The
function casts the actual parameter to the type specified in the
function definition.
</description>
</rule>
<rule>
<key>C4090</key>
<configkey>C4090</configkey>
<priority>CRITICAL</priority>
<name>warning C4090: 'operation' : different 'modifier' qualifiers</name>
<description>
A variable used in an operation is defined with a
specified modifier that prevents it from being modified without
detection by the compiler. The expression is compiled without
modification.
This warning can be caused when a pointer to a const or volatile item is
assigned to a pointer not declared as pointing to const or volatile.
</description>
</rule>
<rule>
<key>C4091</key>
<configkey>C4091</configkey>
<priority>CRITICAL</priority>
<name>warning C4091: 'keyword' : ignored on left of 'type' when no variable is
declared</name>
<description>
The compiler detected a situation where the user probably
intended a variable to be declared, but the compiler was not able to
declare the variable.
</description>
</rule>
<rule>
<key>C4092</key>
<configkey>C4092</configkey>
<priority>CRITICAL</priority>
<name>warning C4092: sizeof returns 'unsigned long'</name>
<description>
The operand of the sizeof operator was very large, so
sizeof returned an unsigned long. This warning occurs under the
Microsoft extensions (/Ze). Under ANSI compatibility (/Za), the
result is truncated instead.
</description>
</rule>
<rule>
<key>C4094</key>
<configkey>C4094</configkey>
<priority>CRITICAL</priority>
<name>warning C4094: untagged 'token' declared no symbols</name>
<description>
The compiler detected an empty declaration using an
untagged structure, union, or class. The declaration is ignored.
</description>
</rule>
<rule>
<key>C4096</key>
<configkey>C4096</configkey>
<priority>CRITICAL</priority>
<name>warning C4096: 'a': interface is not a COM interface; will not be emitted to
IDL</name>
<description>
An interface definition that you may have intended as a
COM interface was not defined as a COM interface and therefore will
not be emitted to the IDL file.
</description>
</rule>
<rule>
<key>C4098</key>
<configkey>C4098</configkey>
<priority>CRITICAL</priority>
<name>warning C4098: 'function' : void function returning a value</name>
<description>
A function declared with return type void has a return
statement that returns a value. The compiler assumes the function
returns a value of type int.
</description>
</rule>
<rule>
<key>C4099</key>
<configkey>C4099</configkey>
<priority>CRITICAL</priority>
<name>warning C4099: 'identifier' : type name first seen using 'objecttype1' now seen
using 'objecttype2'</name>
<description>
An object declared as a structure is defined as a class,
or an object declared as a class is defined as a structure. The
compiler uses the type given in the definition.
</description>
</rule>
<rule>
<key>C4100</key>
<configkey>C4100</configkey>
<priority>CRITICAL</priority>
<name>warning C4100: 'identifier' : unreferenced formal variable</name>
<description>
The formal parameter is not referenced in the body of the
function. The unreferenced parameter is ignored. C4100 can also be
issued when code calls a destructor on a otherwise unreferenced
parameter of primitive type. This is a limitation of the Visual C++
compiler.
</description>
</rule>
<rule>
<key>C4101</key>
<configkey>C4101</configkey>
<priority>CRITICAL</priority>
<name>warning C4101: 'identifier' : unreferenced local variable</name>
<description>
The local variable is never used.
</description>
</rule>
<rule>
<key>C4103</key>
<configkey>C4103</configkey>
<priority>CRITICAL</priority>
<name>warning C4103: 'filename' : alignment changed after including header, may be due to missing #pragma pack(pop)</name>
<description>
Packing affects the layout of classes, and commonly, if packing
changes across header files, there can be problems. Use #pragma
pack(pop) before exiting the header file to resolve this warning.
</description>
</rule>
<rule>
<key>C4114</key>
<configkey>C4114</configkey>
<priority>CRITICAL</priority>
<name>warning C4114: same type qualifier used more than once</name>
<description>
A type declaration or definition uses a type qualifier (const,
volatile, signed, or unsigned) more than once. This causes a warning
with Microsoft extensions (/Ze) and an error under ANSI compatibility
(/Za).
</description>
</rule>
<rule>
<key>C4116</key>
<configkey>C4116</configkey>
<priority>CRITICAL</priority>
<name>warning C4116: unnamed type definition in parentheses</name>
<description>
warning C4116: A structure, union, or enumerated type with no
name is defined in a parenthetical expression. The type definition is
meaningless.
</description>
</rule>
<rule>
<key>C4124</key>
<configkey>C4124</configkey>
<priority>CRITICAL</priority>
<name>warning C4124: __fastcall with stack checking is inefficient</name>
<description>
The __fastcall convention generates faster code, but stack
checking causes slower code. When using __fastcall, turn off stack
checking with the check_stack pragma or /Gs.
</description>
</rule>
<rule>
<key>C4129</key>
<configkey>C4129</configkey>
<priority>CRITICAL</priority>
<name>warning C4129: 'character' : unrecognized character escape sequence</name>
<description>
The character following a backslash (\) in a character or string
constant is not recognized as a valid escape sequence. The backslash
is ignored and not printed. The character following the backslash is
printed. To print a single backslash, specify a double backslash
(\\).
</description>
</rule>
<rule>
<key>C4133</key>
<configkey>C4133</configkey>
<priority>CRITICAL</priority>
<name>warning C4133: 'type' : incompatible types - from 'type1' to 'type2'</name>
<description>
This warning can be caused by trying to subtract two pointers of
different types. To avoid this warning, provide an appropriate type
cast.
</description>
</rule>
<rule>
<key>C4142</key>
<configkey>C4142</configkey>
<priority>CRITICAL</priority>
<name>warning C4142: benign redefinition of type</name>
<description>
A type is redefined in a manner that has no effect on the
generated code. To fix by checking the following possible causes: - A
member function of a derived class has a different return type from
the corresponding member function of the base class. - A type defined
with the typedef command is redefined using different syntax.
</description>
</rule>
<rule>
<key>C4144</key>
<configkey>C4144</configkey>
<priority>CRITICAL</priority>
<name>warning C4144: 'expression' : relational expression as switch expression</name>
<description>
The specified relational expression was used as the control
expression of a switch statement. The associated case statements will
be offered Boolean values.
</description>
</rule>
<rule>
<key>C4146</key>
<configkey>C4146</configkey>
<priority>CRITICAL</priority>
<name>warning C4146: unary minus operator applied to unsigned type, result still unsigned</name>
<description>
Unsigned types can hold only non-negative values, so unary minus
(negation) does not usually make sense when applied to an unsigned
type. Both the operand and the result are non-negative. You can avoid
C4146 by using INT_MIN from limits.h, which has the type signed int.
</description>
</rule>
<rule>
<key>C4150</key>
<configkey>C4150</configkey>
<priority>CRITICAL</priority>
<name>warning C4150: deletion of pointer to incomplete type 'type'; no destructor called</name>
<description>
The delete operator is called to delete a type that was declared
but not defined, so the compiler cannot find a destructor.
</description>
</rule>
<rule>
<key>C4154</key>
<configkey>C4154</configkey>
<priority>CRITICAL</priority>
<name>warning C4154: deletion of an array expression; conversion to pointer supplied</name>
<description>
You cannot use delete on an array, so the compiler converts the
array to a pointer.
</description>
</rule>
<rule>
<key>C4156</key>
<configkey>C4156</configkey>
<priority>CRITICAL</priority>
<name>warning C4156: deletion of an array expression without using the array form of 'delete'; array form substituted</name>
<description>
The non-array form of delete cannot delete an array. The
compiler translated delete to the array form. This warning occurs
only under Microsoft extensions (/Ze).
</description>
</rule>
<rule>
<key>C4157</key>
<configkey>C4157</configkey>
<priority>CRITICAL</priority>
<name>warning C4157: pragma was ignored by C compiler</name>
<description>
Only the C++ compiler recognizes init_seg().
</description>
</rule>
<rule>
<key>C4159</key>
<configkey>C4159</configkey>
<priority>CRITICAL</priority>
<name>warning C4159: #pragma pragma(pop,...) : has popped previously pushed identifier 'identifier'</name>
<description>
Your source code contains a push instruction with an identifier
for a pragma followed by a pop instruction without an identifier. As a
result, identifier is popped, and subsequent uses of identifier may
cause unexpected behavior.
</description>
</rule>
<rule>
<key>C4162</key>
<configkey>C4162</configkey>
<priority>CRITICAL</priority>
<name>warning C4162: 'identifier' : no function with C linkage found</name>
<description>
A function with C linkage is declared but cannot be found. To
resolve this warning, compile in a .c file (invoke the C compiler). If
you must invoke the C++ compiler, place extern "C" before the function
declaration.
</description>
</rule>
<rule>
<key>C4172</key>
<configkey>C4172</configkey>
<priority>CRITICAL</priority>
<name>warning C4172: returning address of local variable or temporary</name>
<description>
A function returns the address of a local variable or temporary
object. Local variables and temporary objects are destroyed when a
function returns, so the address returned is not valid. Redesign the
function so that it does not return the address of a local object.
</description>
</rule>
<rule>
<key>C4183</key>
<configkey>C4183</configkey>
<priority>CRITICAL</priority>
<name>warning C4183: 'identifier': missing return type; assumed to be a member function returning 'int'</name>
<description>
The inline definition of a member function in a class or a
structure does not have a return type. This member function is assumed
to have a default return type of int.
</description>
</rule>
<rule>
<key>C4189</key>
<configkey>C4189</configkey>
<priority>CRITICAL</priority>
<name>warning C4189: 'identifier' : local variable is initialized but not referenced</name>
<description>
A variable is declared and initialized but not used.
</description>
</rule>
<rule>
<key>C4190</key>
<configkey>C4190</configkey>
<priority>CRITICAL</priority>
<name>warning C4190: 'identifier1' has C-linkage specified, but returns UDT 'identifier2' which is incompatible with C</name>
<description>
A function or pointer to function has a UDT (user-defined type,
which is a class, structure, enum, union, or __value type) as return
type and extern "C" linkage. This is legal if:
- All calls to this function occur from C++.
- The definition of the function is in C++.
</description>
</rule>
<rule>
<key>C4192</key>
<configkey>C4192</configkey>
<priority>CRITICAL</priority>
<name>warning C4192: automatically excluding 'name' while importing type library 'library'</name>
<description>
A #import library contains an item, name, that is also defined in the Win32 system headers. Due to limitations of type libraries, names such as IUnknown or GUID are often defined in a type library, duplicating the definition from the system headers. #import will detect these items and refuse to incorporate them in the .tlh and .tli header files.
To override this behavior, use #import attributes no_auto_exclude and include().
</description>
</rule>
<rule>
<key>C4197</key>
<configkey>C4197</configkey>
<priority>CRITICAL</priority>
<name>warning C4197: 'type' : top-level volatile in cast is ignored</name>
<description>
The compiler detected a cast to an r-value type which is qualified with volatile, or a cast of an r-value type to some type that is qualified with volatile. According to the C standard (6.5.3), properties associated with qualified types are meaningful only for l-value expressions.
</description>
</rule>
<rule>
<key>C4200</key>
<configkey>C4200</configkey>
<priority>CRITICAL</priority>
<name>warning C4200: nonstandard extension used : zero-sized array in struct/union</name>
<description>
A structure or union contains an array with zero size.
Level-2 warning when compiling a C++ file and a Level-4 warning when compiling a C file.
</description>
</rule>
<rule>
<key>C4201</key>
<configkey>C4201</configkey>
<priority>CRITICAL</priority>
<name>warning C4201: nonstandard extension used : nameless struct/union</name>
<description>
Under Microsoft extensions (/Ze), you can specify a structure without a declarator as members of another structure or union. These structures generate an error under ANSI compatibility (/Za).
</description>
</rule>
<rule>
<key>C4202</key>
<configkey>C4202</configkey>
<priority>CRITICAL</priority>
<name>warning C4202: nonstandard extension used : '...': prototype parameter in name list illegal</name>
<description>
An old-style function definition contains variable arguments. These definitions generate an error under ANSI compatibility (/Za).
</description>
</rule>
<rule>
<key>C4203</key>
<configkey>C4203</configkey>
<priority>CRITICAL</priority>
<name>warning C4203: nonstandard extension used : union with static member variable</name>
<description>
Static union members are valid using Microsoft extensions (/Ze). Such members are invalid in the ANSI standard (/Za). Conforming to the ANSI standard ensures more portable programs.
</description>
</rule>
<rule>
<key>C4204</key>
<configkey>C4204</configkey>
<priority>CRITICAL</priority>
<name>warning C4204: nonstandard extension used : non-constant aggregate initializer</name>
<description>
With Microsoft extensions (/Ze), you can initialize aggregate types (arrays, structures, unions, and classes) with values that are not constants.
</description>
</rule>
<rule>
<key>C4205</key>
<configkey>C4205</configkey>
<priority>CRITICAL</priority>
<name>warning C4205: nonstandard extension used : static function declaration in function scope</name>
<description>
With Microsoft extensions (/Ze), static functions can be declared inside another function. The function is given global scope.
</description>
</rule>
<rule>
<key>C4206</key>
<configkey>C4206</configkey>
<priority>CRITICAL</priority>
<name>warning C4206: nonstandard extension used : translation unit is empty</name>
<description>
The file was empty after preprocessing.
This extension can prevent your code from being portable to other compilers. It generates an error under ANSI compatibility (/Za) and only applies to C source code.
</description>
</rule>
<rule>
<key>C4207</key>
<configkey>C4207</configkey>
<priority>CRITICAL</priority>
<name>warning C4207: nonstandard extension used : extended initializer form</name>
<description>
With Microsoft extensions (/Ze), you can initialize an unsized array of char using a string within braces.
</description>
</rule>
<rule>
<key>C4208</key>
<configkey>C4208</configkey>
<priority>CRITICAL</priority>
<name>warning C4208: nonstandard extension used : delete [exp] - exp evaluated but ignored</name>
<description>
With Microsoft extensions (/Ze), you can delete an array using a value within brackets with the delete operator. The value is ignored.
</description>
</rule>
<rule>
<key>C4210</key>
<configkey>C4210</configkey>
<priority>CRITICAL</priority>
<name>warning C4210: nonstandard extension used : function given file scope</name>
<description>
With the default Microsoft extensions (/Ze), function declarations have file scope.
</description>
</rule>
<rule>
<key>C4211</key>
<configkey>C4211</configkey>
<priority>CRITICAL</priority>
<name>warning C4211: nonstandard extension used : redefined extern to static</name>
<description>
With the default Microsoft extensions (/Ze), you can redefine an extern identifier as static.
</description>
</rule>
<rule>
<key>C4212</key>
<configkey>C4212</configkey>
<priority>CRITICAL</priority>
<name>warning C4212: nonstandard extension used : function declaration used ellipsis</name>
<description>
The function prototype has a variable number of arguments. The function definition does not.
</description>
</rule>
<rule>
<key>C4213</key>
<configkey>C4213</configkey>
<priority>CRITICAL</priority>
<name>warning C4213: nonstandard extension used : cast on l-value</name>
<description>
With the default Microsoft extensions (/Ze), you can use casts on the left side of an assignment statement.
</description>
</rule>
<rule>
<key>C4214</key>
<configkey>C4214</configkey>
<priority>CRITICAL</priority>
<name>warning C4214: nonstandard extension used : bit field types other than int</name>
<description>
With the default Microsoft extensions (/Ze), bitfield structure members can be of any integer type.
</description>
</rule>
<rule>
<key>C4215</key>
<configkey>C4215</configkey>
<priority>CRITICAL</priority>
<name>warning C4215: nonstandard extension used : long float</name>
<description>
The default Microsoft extensions (/Ze) treat long float as double. ANSI compatibility (/Za) does not. Use double to maintain compatibility.
</description>
</rule>
<rule>
<key>C4216</key>
<configkey>C4216</configkey>
<priority>CRITICAL</priority>
<name>warning C4216: nonstandard extension used : float long</name>
<description>
The default Microsoft extensions (/Ze) treat float long as double. ANSI compatibility (/Za) does not. Use double to maintain compatibility.
</description>
</rule>
<rule>
<key>C4218</key>
<configkey>C4218</configkey>
<priority>CRITICAL</priority>
<name>warning C4218: nonstandard extension used : must specify at least a storage class or a type</name>
<description>
With the default Microsoft extensions (/Ze), you can declare a variable without specifying a type or storage class. The default type is int.
</description>
</rule>
<rule>
<key>C4220</key>
<configkey>C4220</configkey>
<priority>CRITICAL</priority>
<name>warning C4220: varargs matches remaining parameters</name>
<description>
Under the default Microsoft extensions (/Ze), a pointer to a function matches a pointer to a function with similar, but variable, arguments
</description>
</rule>
<rule>
<key>C4221</key>
<configkey>C4221</configkey>
<priority>CRITICAL</priority>
<name>warning C4221: nonstandard extension used : 'identifier' : cannot be initialized using address of automatic variable</name>
<description>
With the default Microsoft extensions (/Ze), you can initialize an aggregate type (array, struct, or union) with the address of a local (automatic) variable.
</description>
</rule>
<rule>
<key>C4223</key>
<configkey>C4223</configkey>
<priority>CRITICAL</priority>
<name>warning C4223: nonstandard extension used : non-lvalue array converted to pointer</name>
<description>
In standard C, you cannot convert a non-lvalue array to a pointer. With the default Microsoft extensions (/Ze), you can.
</description>
</rule>
<rule>
<key>C4224</key>
<configkey>C4224</configkey>
<priority>CRITICAL</priority>
<name>warning C4224: nonstandard extension used : formal parameter 'identifier' was previously defined as a type</name>
<description>
The identifier was previously used as a typedef. This causes a warning under ANSI compatibility (/Za).
</description>
</rule>
<rule>
<key>C4226</key>
<configkey>C4226</configkey>
<priority>CRITICAL</priority>
<name>warning C4226: nonstandard extension used : 'keyword' is an obsolete keyword</name>
<description>
The current version of Visual C++ does not use this keyword.
</description>
</rule>
<rule>
<key>C4227</key>
<configkey>C4227</configkey>
<priority>CRITICAL</priority>
<name>warning C4227: anachronism used : qualifiers on reference are ignored</name>
<description>
Using qualifiers like const or volatile with C++ references is an outdated practice.
</description>
</rule>
<rule>
<key>C4228</key>
<configkey>C4228</configkey>
<priority>CRITICAL</priority>
<name>warning C4228: nonstandard extension used : qualifiers after comma in declarator list are ignored</name>
<description>
Use of qualifiers like const or volatile after a comma when declaring variables is a Microsoft extension (/Ze).
</description>
</rule>
<rule>
<key>C4229</key>
<configkey>C4229</configkey>
<priority>CRITICAL</priority>
<name>warning C4229: anachronism used : modifiers on data are ignored</name>
<description>
Using a Microsoft modifier such as __cdecl on a data declaration is an outdated practice.
</description>
</rule>
<rule>
<key>C4230</key>
<configkey>C4230</configkey>
<priority>CRITICAL</priority>
<name>warning C4230: anachronism used : modifiers/qualifiers interspersed; qualifier ignored</name>
<description>
Using a qualifier before a Microsoft modifier such as __cdecl is an outdated practice.
</description>
</rule>
<rule>
<key>C4231</key>
<configkey>C4231</configkey>
<priority>CRITICAL</priority>
<name>warning C4231: nonstandard extension used : 'identifier' before template explicit instantiation</name>
<description>
When Microsoft extensions are enabled (/Ze), an extern template can be instantiated, generating this warning. Under ANSI compatibility (/Za), such instantiations cause an error.
</description>
</rule>
<rule>
<key>C4232</key>
<configkey>C4232</configkey>
<priority>CRITICAL</priority>
<name>warning C4232: nonstandard extension used : 'identifier' : address of dllimport 'dllimport' is not static, identity not guaranteed</name>
<description>
Under Microsoft extensions (/Ze), you can give a nonstatic value as the address of a function declared with the dllimport modifier. Under ANSI compatibility (/Za), this causes an error.
</description>
</rule>
<rule>
<key>C4233</key>
<configkey>C4233</configkey>
<priority>CRITICAL</priority>
<name>warning C4233: nonstandard extension used : 'keyword' keyword only supported in C++, not C</name>
<description>
The compiler compiled your source code as C rather than C++, and you used a keyword that is only valid in C++. The compiler compiles your source file as C if the extension of the source file is .c or you use /Tc.
</description>
</rule>
<rule>
<key>C4234</key>
<configkey>C4234</configkey>
<priority>CRITICAL</priority>
<name>warning C4234: nonstandard extension used: 'keyword' keyword reserved for future use</name>
<description>
The compiler does not yet implement the keyword you used.
This warning is automatically promoted to an error. If you wish to modify this behavior, use #pragma warning.
</description>
</rule>
<rule>
<key>C4235</key>
<configkey>C4235</configkey>
<priority>CRITICAL</priority>
<name>warning C4235: nonstandard extension used : 'keyword' keyword not supported on this architecture</name>
<description>
The compiler does not support the keyword you used.
For example, the _asm keyword is not supported for the Itanium Processor Family (IPF) compiler. All assembly code must be written in a separate file or should be used through an intrinsic. See Intrinsics Available on Intel 64-bit Platforms for more information.
This warning is automatically promoted to an error. If you wish to modify this behavior, use #pragma warning.
</description>
</rule>
<rule>
<key>C4237</key>
<configkey>C4237</configkey>
<priority>CRITICAL</priority>
<name>warning C4237: 'keyword' keyword is not yet supported, but reserved for future use</name>
<description>
A keyword in the C++ specification is not implemented in the Visual C++ compiler, but the keyword is not available as a user-defined symbol.
</description>
</rule>
<rule>
<key>C4238</key>
<configkey>C4238</configkey>
<priority>CRITICAL</priority>
<name>warning C4238: nonstandard extension used : class rvalue used as lvalue</name>
<description>
For compatibility with previous versions of Visual C++, Microsoft extensions (/Ze) allow you to use a class type as an rvalue in a context that implicitly or explicitly takes its address. In some cases, such as the example below, this can be dangerous.
</description>
</rule>
<rule>
<key>C4239</key>
<configkey>C4239</configkey>
<priority>CRITICAL</priority>
<name>warning C4239: nonstandard extension used : 'token' : conversion from 'type' to 'type'</name>
<description>
This type conversion is not allowed by the C++ standard, but it is permitted here as an extension. This warning is always followed by at least one line of explanation describing the language rule being violated.
</description>
</rule>
<rule>
<key>C4240</key>
<configkey>C4240</configkey>
<priority>CRITICAL</priority>
<name>warning C4240: nonstandard extension used : access to 'classname' now defined to be 'access specifier', previously it was defined to be 'access specifier'</name>
<description>
Under ANSI compatibility (/Za), you cannot change the access to a nested class. Under the default Microsoft extensions (/Ze), you can, with this warning.
</description>
</rule>
<rule>
<key>C4242</key>
<configkey>C4242</configkey>
<priority>CRITICAL</priority>
<name>warning C4242: 'identifier' : conversion from 'type1' to 'type2', possible loss of data</name>
<description>
The types are different. Type conversion may result in loss of data. The compiler makes the type conversion.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
For additional information on C4242, see Common Compiler Errors.
</description>
</rule>
<rule>
<key>C4243</key>
<configkey>C4243</configkey>
<priority>CRITICAL</priority>
<name>warning C4243: 'conversion type' conversion exists from 'type1' to 'type2', but is inaccessible</name>
<description>
A pointer to a derived class is converted to a pointer to a base class, but the derived class inherits the base class with private or protected access.
</description>
</rule>
<rule>
<key>C4244</key>
<configkey>C4244</configkey>
<priority>CRITICAL</priority>
<name>warning C4244: 'argument' : conversion from 'type1' to 'type2', possible loss of data</name>
<description>
(/W2)A floating point type was converted to an integer type. A possible loss of data may have occurred.
If you get C4244, you should either change your program to use compatible types, or add some logic to your code, to ensure that the range of possible values will always be compatible with the types you are using.
(/W3, /W4) An integer type is converted to a smaller integer type. This is a level-4 warning if type1 is int and type2 is smaller than int. Otherwise, it is a level 3 (assigned a value of type __int64 to a variable of type unsigned int). A possible loss of data may have occurred.
If you get C4244, you should either change your program to use compatible types, or add some logic to your code, to ensure that the range of possible values will always be compatible with the types you are using.
</description>
</rule>
<rule>
<key>C4245</key>
<configkey>C4245</configkey>
<priority>CRITICAL</priority>
<name>warning C4245: 'conversion' : conversion from 'type1' to 'type2', signed/unsigned mismatch</name>
<description>
You tried to convert a signed const that has a negative value to an unsigned.
</description>
</rule>
<rule>
<key>C4250</key>
<configkey>C4250</configkey>
<priority>CRITICAL</priority>
<name>warning C4250: 'class1' : inherits 'class2::member' via dominance</name>
<description>
Two or more members have the same name. The one in class2 is inherited because it is a base class for the other classes that contained this member.
To suppress C4250, use the warning pragma.
Because a virtual base class is shared among multiple derived classes, a name in a derived class dominates a name in a base class. For example, given the following class hierarchy, there are two definitions of func inherited within diamond: the vbc::func() instance through the weak class, and the dominant::func() through the dominant class. An unqualified call of func() through a diamond class object, always calls the dominate::func() instance. If the weak class were to introduce an instance of func(), neither definition would dominate, and the call would be flagged as ambiguous.
</description>
</rule>
<rule>
<key>C4251</key>
<configkey>C4251</configkey>
<priority>CRITICAL</priority>
<name>warning C4251: 'identifier' : class 'type' needs to have dll-interface to be used by clients of class 'type2'</name>
<description>
To minimize the possibility of data corruption when exporting a class with __declspec(dllexport), ensure that:
- All your static data is access through functions that are exported from the DLL.
- No inlined methods of your class can modify static data.
- No inlined methods of your class use CRT functions or other library functions use static data (see Potential Errors Passing CRT Objects Across DLL Boundaries for more information).
- No methods of your class (regardless of inlining) can use types where the instantiation in the EXE and DLL have static data differences.
You can avoid exporting classes by defining a DLL that defines a class with virtual functions, and functions you can call to instantiate and delete objects of the type. You can then just call virtual functions on the type.
C4251 can be ignored if you are deriving from a type in the Standard C++ Library, compiling a debug release (/MTd) and where the compiler error message refers to _Container_base.
</description>
</rule>
<rule>
<key>C4254</key>
<configkey>C4254</configkey>
<priority>CRITICAL</priority>
<name>warning C4254: 'operator' : conversion from 'type1' to 'type2', possible loss of data</name>
<description>
A larger bit field was assigned to a smaller bit field. There could be a loss of data.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4255</key>
<configkey>C4255</configkey>
<priority>CRITICAL</priority>
<name>warning C4255: 'function' : no function prototype given: converting '()' to '(void)'</name>
<description>
The compiler did not find an explicit list of arguments to a function. This warning is for the C compiler only.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4256</key>
<configkey>C4256</configkey>
<priority>CRITICAL</priority>
<name>warning C4256: 'function' : constructor for class with virtual bases has '...'; calls may not be compatible with older versions of Visual C++</name>
<description>
Possible incompatibility.
Consider the following code example. If the definition of the constructor S2::S2( int i, ... ) was compiled by using a version of the Visual C++ compiler before version 7, but the following example is compiled by using the current version, the call to the constructor for S3 would not work correctly because of a special-case calling-convention change. If both were compiled by using Visual C++ 6.0, the call would not work quite right either, unless no parameters were passed for the ellipsis.
To fix this warning,
- Don't use ellipsis in a constructor.
- Make sure that all components in their project are built with the current version (including any libraries that may define or reference this class), then disable the warning using the warning pragma.
</description>
</rule>
<rule>
<key>C4258</key>
<configkey>C4258</configkey>
<priority>CRITICAL</priority>
<name>warning C4258: 'variable' : definition from the for loop is ignored; the definition from the enclosing scope is used"</name>
<description>
Under /Ze and /Zc:forScope, variables defined in a for loop go out of scope after the for loop ends. This warning occurs if a variable with the same name as the loop variable, but defined in the enclosing loop, is used again in the scope containing the for loop.
</description>
</rule>
<rule>
<key>C4263</key>
<configkey>C4263</configkey>
<priority>CRITICAL</priority>
<name>warning C4263: 'function' : member function does not override any base class virtual member function</name>
<description>
A class function definition has the same name as a virtual function in a base class but not the same number or type of arguments. This effectively hides the virtual function in the base class.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4264</key>
<configkey>C4264</configkey>
<priority>CRITICAL</priority>
<name>warning C4264: 'virtual_function' : no override available for virtual member function from base 'class'; function is hidden</name>
<description>
C4264 is always generated after C4263.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4265</key>
<configkey>C4265</configkey>
<priority>CRITICAL</priority>
<name>warning C4265: 'class' : class has virtual functions, but destructor is not virtual</name>
<description>
When a class has virtual functions but a nonvirtual destructor, objects of the type might not be destroyed properly when the class is destroyed through a base class pointer.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4266</key>
<configkey>C4266</configkey>
<priority>CRITICAL</priority>
<name>warning C4266: 'function' : no override available for virtual member function from base 'type'; function is hidden</name>
<description>
A derived class did not override all overloads of a virtual function.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4267</key>
<configkey>C4267</configkey>
<priority>CRITICAL</priority>
<name>warning C4267: 'var' : conversion from 'size_t' to 'type', possible loss of data</name>
<description>
When compiling with /Wp64, or when compiling on a 64-bit operating system, type is 32 bits but size_t is 64 bits when compiling for 64-bit targets.
To fix this warning, use size_tinstead of a type.
</description>
</rule>
<rule>
<key>C4268</key>
<configkey>C4268</configkey>
<priority>CRITICAL</priority>
<name>warning C4268: 'identifier' : 'const' static/global data initialized with compiler generated default constructor fills the object with zeros</name>
<description>
A const global or static instance of a non-trivial class is initialized with a compiler-generated default constructor.
</description>
</rule>
<rule>
<key>C4269</key>
<configkey>C4269</configkey>
<priority>CRITICAL</priority>
<name>warning C4269: 'identifier' : 'const' automatic data initialized with compiler generated default constructor produces unreliable results</name>
<description>
A const automatic instance of a non-trivial class is initialized with a compiler-generated default constructor.
</description>
</rule>
<rule>
<key>C4272</key>
<configkey>C4272</configkey>
<priority>CRITICAL</priority>
<name>warning C4272: 'function' : is marked __declspec(dllimport); must specify native calling convention when importing a function.</name>
<description>
It is an error to export a function marked with the __clrcall calling convention, and the compiler issues this warning if you attempt to import a function marked __clrcall.
</description>
</rule>
<rule>
<key>C4273</key>
<configkey>C4273</configkey>
<priority>CRITICAL</priority>
<name>warning C4273: 'function' : inconsistent DLL linkage</name>
<description>
Two definitions in a file differ in their use of dllimport.
</description>
</rule>
<rule>
<key>C4275</key>
<configkey>C4275</configkey>
<priority>CRITICAL</priority>
<name>warning C4275: non – DLL-interface classkey 'identifier' used as base for DLL-interface classkey 'identifier'</name>
<description>
An exported class was derived from a class that was not exported.
To minimize the possibility of data corruption when exporting a class with __declspec(dllexport), ensure that:
- All your static data is accessed through functions that are exported from the DLL.
- No inlined methods of your class can modify static data.
- No inlined methods of your class use CRT functions or other library functions use static data.
- No inlined class functions use CRT functions, or other library functions, where, for example, you access static data.
- No methods of your class (regardless of inlining) can use types where the instantiation in the EXE and DLL have static data differences.
You can avoid exporting classes by defining a DLL that defines a class with virtual functions, and functions you can call to instantiate and delete objects of the type. You can then just call virtual functions on the type.
C4275 can be ignored in Visual C++ if you are deriving from a type in the Standard C++ Library, compiling a debug release (/MTd) and where the compiler error message refers to _Container_base.
</description>
</rule>
<rule>
<key>C4276</key>
<configkey>C4276</configkey>
<priority>CRITICAL</priority>
<name>warning C4276: 'function' : no prototype provided; assumed no parameters</name>
<description>
When you take the address of a function with the __stdcall calling convention, you must give a prototype so the compiler can create the function's decorated name. Since function has no prototype, the compiler, when creating the decorated name, assumes the function has no parameters.
</description>
</rule>
<rule>
<key>C4278</key>
<configkey>C4278</configkey>
<priority>CRITICAL</priority>
<name>warning C4278: 'identifier': identifier in type library 'tlb' is already a macro; use the 'rename' qualifier</name>
<description>
When using #import, an identifier in the typelib you are importing is attempting to declare an identifier identifier. However, this is already a valid symbol.
Use the #import rename attribute to assign an alias to the symbol in the type library.
</description>
</rule>
<rule>
<key>C4280</key>
<configkey>C4280</configkey>
<priority>CRITICAL</priority>
<name>warning C4280: 'operator –>' was self recursive through type 'type'</name>
<description>
Your code incorrectly allows operator–> to call itself.
</description>
</rule>
<rule>
<key>C4281</key>
<configkey>C4281</configkey>
<priority>CRITICAL</priority>
<name>warning C4281: 'operator –>' recursion occurred through type 'type'</name>
<description>
Your code allows operator–> to call itself.
</description>
</rule>
<rule>
<key>C4282</key>
<configkey>C4282</configkey>
<priority>CRITICAL</priority>
<name>warning C4282: then through type 'type'</name>
<description>
This continuation of warning C4281shows that operator–> calls itself through type.
</description>
</rule>
<rule>
<key>C4283</key>
<configkey>C4283</configkey>
<priority>CRITICAL</priority>
<name>warning C4283: and through type 'type'</name>
<description>
This continuation of warning C4281 shows that operator–> calls itself through type.
</description>
</rule>
<rule>
<key>C4285</key>
<configkey>C4285</configkey>
<priority>CRITICAL</priority>
<name>warning C4285: return type for 'identifier::operator –>' is recursive if applied using infix notation</name>
<description>
The specified operator–>() function cannot return the type for which it is defined or a reference to the type for which it is defined.
</description>
</rule>
<rule>
<key>C4286</key>
<configkey>C4286</configkey>
<priority>CRITICAL</priority>
<name>warning C4286: 'type1' : is caught by base class ('type2') on line number</name>
<description>
The specified exception type is handled by a previous handler. The type for the second catch is derived from the type of the first. Exceptions for a base class catch exceptions for a derived class.
</description>
</rule>
<rule>
<key>C4287</key>
<configkey>C4287</configkey>
<priority>CRITICAL</priority>
<name>warning C4287: 'operator' : unsigned/negative constant mismatch</name>
<description>
An unsigned variable was used in an operation with a negative number.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4288</key>
<configkey>C4288</configkey>
<priority>CRITICAL</priority>
<name>warning C4288: nonstandard extension used : 'var' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope</name>
<description>
When compiling with /Ze and /Zc:forscope-, a variable declared in a for loop was used after the for-loop scope. A Microsoft extension to the C++ language allows this variable to remain in scope, and C4288 reminds you that the first declaration of the variable is not used.
See /Zc:forScope for information about how to specify the Microsoft extension in for loops with /Ze.
</description>
</rule>
<rule>
<key>C4289</key>
<configkey>C4289</configkey>
<priority>CRITICAL</priority>
<name>warning C4289: nonstandard extension used : 'var' : loop control variable declared in the for-loop is used outside the for-loop scope</name>
<description>
When compiling with /Ze and /Zc:forScope-, a variable declared in a for loop was used after the for-loop scope.
See /Zc:forScope for information about how to specify standard behavior in for loops with /Ze.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4290</key>
<configkey>C4290</configkey>
<priority>CRITICAL</priority>
<name>warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow)</name>
<description>
A function is declared using exception specification, which Visual C++ accepts but does not implement. Code with exception specifications that are ignored during compilation may need to be recompiled and linked to be reused in future versions supporting exception specifications.
For more information, see Exception Specifications .
</description>
</rule>
<rule>
<key>C4291</key>
<configkey>C4291</configkey>
<priority>CRITICAL</priority>
<name>warning C4291: 'declaration' : no matching operator delete found; memory will not be freed if initialization throws an exception</name>
<description>
A placement new is used for which there is no placement delete.
When memory is allocated for an object with operator new, the object's constructor is called. If the constructor throws an exception, any memory that was allocated for the object should be deallocated. This cannot take place unless an operator delete function exists that matches the operator new.
If you use the operator new without any extra arguments and compile with /GX, /EHs, or /EHa options to enable exception handling, the compiler will generate code to call operator delete if the constructor throws an exception.
If you use the placement form of the new operator (the form with arguments in addition to the size of the allocation) and the object's constructor throws an exception, the compiler will still generate code to call operator delete; but it will only do so if a placement form of operator delete exists matching the placement form of the operator new that allocated the memory.
</description>
</rule>
<rule>
<key>C4293</key>
<configkey>C4293</configkey>
<priority>CRITICAL</priority>
<name>warning C4293: 'operator' : shift count negative or too big, undefined behavior</name>
<description>
If a shift count is negative or too large, the behavior of the resulting image is undefined.
</description>
</rule>
<rule>
<key>C4295</key>
<configkey>C4295</configkey>
<priority>CRITICAL</priority>
<name>warning C4295: ' array ' : array is too small to include a terminating null character</name>
<description>
An array was initialized but the last character in the array is not a null; accessing the array may produce unexpected results.
</description>
</rule>
<rule>
<key>C4296</key>
<configkey>C4296</configkey>
<priority>CRITICAL</priority>
<name>warning C4296: 'operator' : expression is always false</name>
<description>
An unsigned variable was used in a comparison operation with zero.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4297</key>
<configkey>C4297</configkey>
<priority>CRITICAL</priority>
<name>warning C4297: 'function' : function assumed not to throw an exception but does</name>
<description>
A function contains a nothrow declaration and one or more throw statements. To resolve C4297, do not attempt to throw exceptions in functions that are declared with nothrow or to remove the nothrow specification.
For more information on exception specifications, see Exception Specifications. Also, see /EH (Exception Handling Model) for information on how to modify exception handling behavior at compile time.
This warning is also generated for __declspec(dllexport) functions marked extern "C", even if they are C++ functions.
</description>
</rule>
<rule>
<key>C4302</key>
<configkey>C4302</configkey>
<priority>CRITICAL</priority>
<name>warning C4302: 'conversion' : truncation from 'type 1' to 'type 2'</name>
<description>
The compiler detected a conversion from a larger type to a smaller type. Information may be lost.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4303</key>
<configkey>C4303</configkey>
<priority>CRITICAL</priority>
<name>warning C4303: 'cast' from 'type1' to 'type2' is deprecated, use static_cast, __try_cast or dynamic_cast</name>
<description>
C-style type casting or function-style casting is not supported when using Managed Extensions for C++. To cast, use either dynamic_cast Operator or static_cast Operator.
C4303 is not reachable using /clr and the new syntax; see C-Style Casts with /clr for more information.
</description>
</rule>
<rule>
<key>C4305</key>
<configkey>C4305</configkey>
<priority>CRITICAL</priority>
<name>warning C4305: 'identifier' : truncation from 'type1' to 'type2'</name>
<description>
If you used the ATL Connection Point Wizard, see Knowledge Base article:
Q250847 : ATL Connection Point Wizard Generated Code for Event with VARIANT Argument Gives C4305 Warning
</description>
</rule>
<rule>
<key>C4306</key>
<configkey>C4306</configkey>
<priority>CRITICAL</priority>
<name>warning C4306: 'identifier' : conversion from 'type1' to 'type2' of greater size</name>
<description>
The identifier is type cast to a larger pointer. The unfilled high bits of the new type will be zero-filled.
This warning may indicate an unwanted conversion. The resulting pointer may not be valid.
</description>
</rule>
<rule>
<key>C4307</key>
<configkey>C4307</configkey>
<priority>CRITICAL</priority>
<name>warning C4307: 'operator' : integral constant overflow</name>
<description>
The operator is used in an expression that results in an integer constant overflowing the space allocated for it. You may need to use a larger type for the constant. A signed int holds a smaller value than an unsigned int because the signed int uses one bit to represent the sign.
</description>
</rule>
<rule>
<key>C4308</key>
<configkey>C4308</configkey>
<priority>CRITICAL</priority>
<name>warning C4308: negative integral constant converted to unsigned type</name>
<description>
An expression converts a negative integer constant to an unsigned type. The result of the expression is probably meaningless.
</description>
</rule>
<rule>
<key>C4309</key>
<configkey>C4309</configkey>
<priority>CRITICAL</priority>
<name>warning C4309: 'conversion' : truncation of constant value</name>
<description>
The type conversion causes a constant to exceed the space allocated for it. You may need to use a larger type for the constant.
</description>
</rule>
<rule>
<key>C4310</key>
<configkey>C4310</configkey>
<priority>CRITICAL</priority>
<name>warning C4310: cast truncates constant value</name>
<description>
A constant value is cast to a smaller type. The compiler performs the cast, which truncates data.
</description>
</rule>
<rule>
<key>C4311</key>
<configkey>C4311</configkey>
<priority>CRITICAL</priority>
<name>warning C4311: 'variable' : pointer truncation from 'type' to 'type'</name>
<description>
This warning detects 64-bit portability issues. For example, if code is compiled on a 64-bit platform, the value of a pointer (64 bits) will be truncated if it is assigned to an int (32 bits).
This warning is only issued when /Wp64 is used. See /Wp64 for more information. Also, see Rules for Using Pointers.
For additional information on C4311, see Common Compiler Errors.
</description>
</rule>
<rule>
<key>C4312</key>
<configkey>C4312</configkey>
<priority>CRITICAL</priority>
<name>warning C4312: 'operation' : conversion from 'type1' to 'type2' of greater size</name>
<description>
This warning detects 64-bit portability issues. You attempted to assign a 32-bit value to a 64-bit type. For example, casting a 32-bit int or 32-bit long to a 64-bit pointer.
This can be an unsafe conversion in some circumstances when sign extension occurs. If a negative number is assigned to a pointer type of a size greater than the int, sign extension will occur and the pointer value will refer to a memory address different from the value of the int.
This warning is only issued when /Wp64 is used. See /Wp64 for more information. Also, see Rules for Using Pointers.
</description>
</rule>
<rule>
<key>C4313</key>
<configkey>C4313</configkey>
<priority>CRITICAL</priority>
<name>warning C4313: 'function' : 'format specifier' in format string conflicts with argument %d of type 'type'</name>
<description>
There is a conflict between the format specified and the value that you are passing. For example, you passed a 32-bit pointer to %d format specifier, which can hold a 64-bit integer. This warning is only in effect with /Wp64.
</description>
</rule>
<rule>
<key>C4318</key>
<configkey>C4318</configkey>
<priority>CRITICAL</priority>
<name>warning C4318: passing constant zero as the length to memset</name>
<description>
You called the C run-time library's memset function with a zero character length. For example, memset(p,size,0). Instead, specify memset(p,0,size).
</description>
</rule>
<rule>
<key>C4319</key>
<configkey>C4319</configkey>
<priority>CRITICAL</priority>
<name>warning C4319: 'operator' : zero extending 'type' to 'type' of greater size</name>
<description>
The result of the ~ operator is unsigned and then converted to a larger type.
In the following example, ~(a - 1) is evaluated as a 32-bit unsigned long expression and then converted to 64 bits by zero extension. This leads to pointer truncations.
</description>
</rule>
<rule>
<key>C4324</key>
<configkey>C4324</configkey>
<priority>CRITICAL</priority>
<name>warning C4324: 'struct_name' : structure was padded due to __declspec(align())</name>
<description>
Padding was added at the end of a structure because you specified a __declspec(align) value.
</description>
</rule>
<rule>
<key>C4325</key>
<configkey>C4325</configkey>
<priority>CRITICAL</priority>
<name>warning C4325: attributes for standard section ' section ' ignored</name>
<description>
You may not change the attributes of a standard section.
This would overwrite the .sdata standard section which uses the short data type with the long data type.
Standard sections whose attributes you may not change include,
.data
.sdata
.bss
.sbss
.text
.const
.sconst
.rdata
.srdata
</description>
</rule>
<rule>
<key>C4326</key>
<configkey>C4326</configkey>
<priority>CRITICAL</priority>
<name>warning C4326: return type of 'function' should be 'type1' instead of 'type2'</name>
<description>
A function returned a type other than type1. For example, using /Za, main did not return an int.
</description>
</rule>
<rule>
<key>C4329</key>
<configkey>C4329</configkey>
<priority>CRITICAL</priority>
<name>warning C4329: __declspec(align()) is ignored on enum</name>
<description>
Use of the align keyword of the __declspec modifier is not allowed on an enum
</description>
</rule>
<rule>
<key>C4333</key>
<configkey>C4333</configkey>
<priority>CRITICAL</priority>
<name>warning C4333: 'operator' : right shift by too large amount, data loss</name>
<description>
A right shift operation was too large an amount. All significant bits are shifted out and the result will always be zero.
</description>
</rule>
<rule>
<key>C4334</key>
<configkey>C4334</configkey>
<priority>CRITICAL</priority>
<name>warning C4334: 'operator' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)</name>
<description>
The result of 32-bit shift was implicitly converted to 64-bits, and the compiler suspects that a 64-bit shift was intended. To resolve this warning, either use 64-bit shift, or explicitly cast the shift result to 64-bit.
</description>
</rule>
<rule>
<key>C4335</key>
<configkey>C4335</configkey>
<priority>CRITICAL</priority>
<name>warning C4335: Mac file format detected: please convert the source file to either DOS or UNIX format</name>
<description>
The line termination character of the first line of a source file is Macintosh style (‘\r’) as opposed to UNIX (‘\n’) or DOS (‘\r\n’).
This warning is always issued as an errror. See warning pragma for information about how to disable this warning. Also, this warning is only issued once per compiland. Therefore, if there are multiple #include directives that specify files in Macintosh format, C4335 will only be issued once.
One way to generate files in Macintosh format is by using the Advanced Save Options (on the File menu) in Visual Studio.
</description>
</rule>
<rule>
<key>C4336</key>
<configkey>C4336</configkey>
<priority>CRITICAL</priority>
<name>warning C4336: import cross-referenced type library 'type_lib1' before importing 'type_lib2'</name>
<description>
A type library was referenced with the #import directive. However, the type library contained a reference to another type library that was not referenced with #import. This other .tlb file was found by the compiler.
</description>
</rule>
<rule>
<key>C4337</key>
<configkey>C4337</configkey>
<priority>CRITICAL</priority>
<name>warning C4337: cross-referenced type library 'typelib1' in 'typelib2' is being automatically imported</name>
<description>
The auto_search attribute of the #import directive caused a type library to be implicitly imported.
</description>
</rule>
<rule>
<key>C4339</key>
<configkey>C4339</configkey>
<priority>CRITICAL</priority>
<name>warning C4339: 'type' : use of undefined type detected in CLR meta-data - use of this type may lead to a runtime exception</name>
<description>
A type was not defined in code that was compiled for the common language runtime. Define the type to avoid a possible runtime exception.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4340</key>
<configkey>C4340</configkey>
<priority>CRITICAL</priority>
<name>warning C4340: 'value' : value wrapped from positive to negative value</name>
<description>
The enum value is greater than the largest enum positive value wrapped around to a negative value.
</description>
</rule>
<rule>
<key>C4341</key>
<configkey>C4341</configkey>
<priority>CRITICAL</priority>
<name>warning C4341: 'value' : signed value is out of range for enum constant</name>
<description>
An enumerated constant exceeds the limit for an int. The value of the invalid constant is undefined. Constants must resolve to integers between –4,294,967,295 and +4,294,967,295 (signed).
Note that this is a level 3 warning under /Ze and a level 1 warning under /Za.
</description>
</rule>
<rule>
<key>C4342</key>
<configkey>C4342</configkey>
<priority>CRITICAL</priority>
<name>warning C4342: behavior change: 'function' called, but a member operator was called in previous versions</name>
<description>
In previous versions of Visual C++, a member was called, but this behavior has been changed and the compiler will find the best match in namespace scope.
If a member operator was found, the compiler would previously not consider any namespace scope operators. If there is a better match at namespace scope, the current compiler will correctly call it, whereas previous compilers wouldn't consider it.
This warning should be disabled after you successfully port your code to the current version. The compiler may give false positives, generating this warning for code where there is no behavior change.
This warning is off by default. For more information, see Compiler Warnings That Are Off by Default.
</description>
</rule>
<rule>
<key>C4343</key>
<configkey>C4343</configkey>
<priority>CRITICAL</priority>
<name>warning C4343: #pragma optimize("g",off) overrides /Og option</name>
<description>
This warning, only valid in the Itanium Processor Family (IPF) compiler, reports that a pragma optimize overrode a /Og compiler option.
</description>
</rule>
<rule>
<key>C4344</key>
<configkey>C4344</configkey>
<priority>CRITICAL</priority>
<name>warning C4344: behavior change: use of explicit template arguments results in call to 'function'</name>
<description>
A call to a function using explicit template arguments calls a different function than it would if explicit arguments had not been specified
</description>
</rule>
<rule>
<key>C4345</key>
<configkey>C4345</configkey>
<priority>CRITICAL</priority>
<name>warning C4345: behavior change: an object of POD type constructed with an initializer of the form () will be default-initialized</name>
<description>
This warning reports a behavior change from the Visual C++ compiler that shipped in Visual Studio .NET when initializing a POD (plain old data) object with (); the compiler will default-initialize the object.
</description>
</rule>
<rule>
<key>C4346</key>
<configkey>C4346</configkey>
<priority>CRITICAL</priority>
<name>warning C4346: 'name' : dependent name is not a type</name>
<description>
The typename keyword is required if a dependent name is to be treated as a type. This is a breaking change in the Visual C++ .NET 2003 compiler, made in order to conform to the ISO C++ standard.
For code that works the same in all versions of Visual C++, add typename to the declaration.
</description>
</rule>
<rule>
<key>C4347</key>
<configkey>C4347</configkey>
<priority>CRITICAL</priority>
<name>warning C4347: behavior change: 'function template' is called instead of 'function'</name>
<description>
In Visual Studio .NET, if you had a template function and a nontemplate function with the same name as the template function, the compiler incorrectly treated the nontemplate function as a specialization of the template function.
For code that works the same in all versions of Visual C++, add template<> above the nontemplate function, making it a real explicit specialization.
This warning is off by default. For more information, see Compiler Warnings That Are Off by Default.
</description>
</rule>
<rule>
<key>C4348</key>
<configkey>C4348</configkey>
<priority>CRITICAL</priority>
<name>warning C4348: 'type' : redefinition of default parameter : parameter number</name>
<description>
A template parameter was redefined.
</description>
</rule>
<rule>
<key>C4350</key>
<configkey>C4350</configkey>
<priority>CRITICAL</priority>
<name>warning C4350: behavior change: 'member1' called instead of 'member2'</name>
<description>
An rvalue cannot be bound to a non-const reference. In previous versions of Visual C++, it was possible to bind an rvalue to a non-const reference in a direct initialization. This code now gives a warning.
For backward compatibility, it is still possible to bind rvalues to non-const references, but standard conversions are preferred wherever possible.
This warning represents a change of behavior from the Visual C++ .NET 2002 compiler. If enabled, this warning could possibly be given for correct code. For example, it could be given when using the std::auto_ptr class template.
If you get this warning, examine your code to see if it depends on binding rvalues to non-const references. Adding a const to the reference or providing a additional const-reference overload may solve the problem.
This warning is off by default. For more information, see Compiler Warnings That Are Off by Default.
</description>
</rule>
<rule>
<key>C4351</key>
<configkey>C4351</configkey>
<priority>CRITICAL</priority>
<name>warning C4351: new behavior: elements of array 'array' will be default initialized</name>
<description>
When an array is in a constructor's member initialization list, the elements of the array will be default initialized. In previous versions of Visual C++, when an array was in a constructor's member initialization list, the elements of the array may not have been default initialized in some cases.
If the array's element type does not have a constructor, the elements of the array will be initialized with the corresponding zero representation for that type.
C4351 means that you should inspect your code. If you want the compiler's previous behavior, remove the array from the constructor's member initialization list.
If you want the new behavior, which is likely, because the array was explicitly added to the constructor's member initialization list, use the warning pragma to disable the warning. The new behavior should be fine for most users.
One situation where the new behavior can result in unexpected behavior is when placement new is used to construct the object that has the array as a member, and the program depends on the contents that the memory (for the elements of the default initialized array) had before the call to placement new. In this case, the older compiler would have left the contents of memory unchanged, but the new behavior will cause default initialization of the array elements, overwriting the original contents in memory.
</description>
</rule>
<rule>
<key>C4353</key>
<configkey>C4353</configkey>
<priority>CRITICAL</priority>
<name>warning C4353: nonstandard extension used: constant 0 as function expression. Use '__noop' function intrinsic instead</name>
<description>
You cannot use the constant zero (0) as a function expression. For more information, see __noop.
</description>
</rule>
<rule>
<key>C4355</key>
<configkey>C4355</configkey>
<priority>CRITICAL</priority>
<name>warning C4355: 'this' : used in base member initializer list</name>
<description>
The this pointer is valid only within nonstatic member functions. It cannot be used in the initializer list for a base class.
The base-class constructors and class member constructors are called before this constructor. In effect, you've passed a pointer to an unconstructed object to another constructor. If those other constructors access any members or call member functions on this, the result will be undefined. You should not use the this pointer until all construction has completed.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4356</key>
<configkey>C4356</configkey>
<priority>CRITICAL</priority>
<name>warning C4356: 'member' : static data member cannot be initialized via derived class</name>
<description>
The initialization of a static data member was ill formed. The compiler accepted the initialization.
This is a breaking change in the Visual C++ .NET 2003 compiler.
For code that works the same in all versions of Visual C++, initialize the member through the base class.
Use the warning pragma to suppress this warning.
</description>
</rule>
<rule>
<key>C4357</key>
<configkey>C4357</configkey>
<priority>CRITICAL</priority>
<name>warning C4357: param array argument in formal argument list for delegate 'del' ignored when generating 'function'</name>
<description>
The ParamArray attribute was ignored, and functioncannot be called with variable arguments.
</description>
</rule>
<rule>
<key>C4358</key>
<configkey>C4358</configkey>
<priority>CRITICAL</priority>
<name>warning C4358: 'operator': return type of combined delegates is not 'void'; returned value is undefined</name>
<description>
Two delegates were combined and the return value is not void. If two delegates with non-void return values are combined, the compiler will not be able to do a proper assignment if the return value of the delegate is used.
</description>
</rule>
<rule>
<key>C4359</key>
<configkey>C4359</configkey>
<priority>CRITICAL</priority>
<name>warning C4359: 'type': actual alignment (8) is greater than the value specified in __declspec(align())</name>
<description>
The alignment specified for a type is less than the alignment of the type of one of its data members. For more information, see align (C++).
</description>
</rule>
<rule>
<key>C4364</key>
<configkey>C4364</configkey>
<priority>CRITICAL</priority>
<name>warning C4364: #using for assembly 'file' previously seen at location(line_number) without as_friend attribute; as_friend not applied</name>
<description>
A #using directive was repeated for a given metadata file, but the as_friend qualifier was not used in the first occurrence; the compiler will ignore the second as_friend.
</description>
</rule>
<rule>
<key>C4365</key>
<configkey>C4365</configkey>
<priority>CRITICAL</priority>
<name>warning C4365: 'action' : conversion from 'type_1' to 'type_2', signed/unsigned mismatch</name>
<description>
For example, you tried to convert an unsigned value to a signed value.
C4365 is off by default. For more information, see Compiler Warnings That Are Off by Default.
</description>
</rule>
<rule>
<key>C4366</key>
<configkey>C4366</configkey>
<priority>CRITICAL</priority>
<name>warning C4366: The result of the unary 'operator' operator may be unaligned</name>
<description>
If a structure member could ever be unaligned because of packing, the compiler will warn when that member's address is assigned to an aligned pointer. By default, all pointers are aligned.
To resolve C4366, either change the alignment of the structure or declare the pointer with the __unaligned keyword.
</description>
</rule>
<rule>
<key>C4368</key>
<configkey>C4368</configkey>
<priority>CRITICAL</priority>
<name>warning C4368: cannot define 'member' as a member of managed 'type': mixed types are not supported</name>
<description>
You can, however, declare a pointer to a native type and control its lifetime in the constructor and destructor and finalizer of your managed class (see Destructors and Finalizers in Visual C++ for more information).
This warning is always issued as an error. Use the warning pragma to disable C4368.
</description>
</rule>
<rule>
<key>C4369</key>
<configkey>C4369</configkey>
<priority>CRITICAL</priority>
<name>warning C4369: 'enumerator' : enumerator value 'value' cannot be represented as 'type', value is 'new_value'</name>
<description>
An enumerator was calculated to be greater than the greatest value for the specified underlying type. This caused an overflow and the compiler wrapped the enumerator value to the lowest possible value for the type.
</description>
</rule>
<rule>
<key>C4374</key>
<configkey>C4374</configkey>
<priority>CRITICAL</priority>
<name>warning C4374: 'function1': interface method will not be implemented by non-virtual method 'function2'</name>
<description>
The compiler expected to find the virtual keyword on a method definition.
</description>
</rule>
<rule>
<key>C4375</key>
<configkey>C4375</configkey>
<priority>CRITICAL</priority>
<name>warning C4375: non-public method 'method2' does not override 'method1'</name>
<description>
A type that implements another type defined an override method, but the override was not public. Therefore, the method does not override the base type method.
</description>
</rule>
<rule>
<key>C4376</key>
<configkey>C4376</configkey>
<priority>CRITICAL</priority>
<name>warning C4376: access specifier 'old_specifier:' is no longer supported: please use 'new_specifier:' instead</name>
<description>
For more information on specifying type and member accessibility in metadata, see Type and Member Visibility.
</description>
</rule>
<rule>
<key>C4377</key>
<configkey>C4377</configkey>
<priority>CRITICAL</priority>
<name>warning C4377: native types are private by default; -d1PrivateNativeTypes is deprecated</name>
<description>
In previous releases, native types in assemblies were public by default, and an internal, undocumented compiler option (/d1PrivateNativeTypes) was used to make them private.
All types, native and CLR, are now private by default in an assembly, so /d1PrivateNativeTypes is no longer needed.
</description>
</rule>
<rule>
<key>C4378</key>
<configkey>C4378</configkey>
<priority>CRITICAL</priority>
<name>warning C4378: Must obtain function pointers to run initializers; consider System::ModuleHandle::ResolveMethodHandle</name>
<description>
Under /clr, initializer symbols contain function tokens, not functions pointers. You need to convert tokens to pointers using ResolveMethodHandle.
</description>
</rule>
<rule>
<key>C4379</key>
<configkey>C4379</configkey>
<priority>CRITICAL</priority>
<name>warning C4379: Version version of the common language runtime is not supported by this compiler. Using this version may cause unexpected results.</name>
<description>
You have a previous version of the common language runtime on your machine, but not the current version. To resolve C4379, install the version of the common language runtime that shipped with your compiler.
</description>
</rule>
<rule>
<key>C4381</key>
<configkey>C4381</configkey>
<priority>CRITICAL</priority>
<name>warning C4381: 'function1': interface method will not be implemented by non-public method 'function2'</name>
<description>
A class must implement all function in an interface. A class can satisfy this condition if one of its base classes implements the function. However, the function must be implemented as a public function.
</description>
</rule>
<rule>
<key>C4382</key>
<configkey>C4382</configkey>
<priority>CRITICAL</priority>
<name>warning C4382: throwing 'type' : a type with __clrcall destructor or copy constructor can only be caught in /clr:pure module</name>
<description>
When compiled with /clr (not /clr:pure), exception handling expects the member functions in a native type to be __cdecl and not __clrcall. Native types with member functions using __clrcall calling convention cannot be caught in a module compiled with /clr.
If the exception will be caught in a module compiled with /clr:pure, you can ignore this warning.
for more information, see /clr (Common Language Runtime Compilation).
</description>
</rule>
<rule>
<key>C4383</key>
<configkey>C4383</configkey>
<priority>CRITICAL</priority>
<name>warning C4383: 'instance_dereference_operator' : meaning of dereferencing a handle can change, when a user-defined 'operator' exists; write operator as a static function to be explicit about operand</name>
<description>
warning C4383: 'instance_dereference_operator' : the meaning of dereferencing a handle can change, when a user-defined 'operator' exists; write the operator as a static function to be explicit about the operand
When you add a user-defined instance override of the dereference operator in a managed type, you potentially override the ability of the type's dereference operator to return the handle's object. Consider writing a static, user-defined dereference operator.
For more information, see Handle to Object Operator (^) and Tracking Reference Operator.
Also, an instance operator is not available to other language compilers via referenced metadata. For more information, see User-Defined Operators.
</description>
</rule>
<rule>
<key>C4384</key>
<configkey>C4384</configkey>
<priority>CRITICAL</priority>
<name>warning C4384: #pragma 'make_public' should only be used at global scope</name>
<description>
The make_public pragma was applied incorrectly.
</description>
</rule>
<rule>
<key>C4389</key>
<configkey>C4389</configkey>
<priority>CRITICAL</priority>
<name>warning C4389: 'operator' : signed/unsigned mismatch</name>
<description>
An operation involved signed and unsigned variables. This could result in a loss of data.
</description>
</rule>
<rule>
<key>C4390</key>
<configkey>C4390</configkey>
<priority>CRITICAL</priority>
<name>warning C4390: ';' : empty controlled statement found; is this the intent?</name>
<description>
A semicolon was found after a control statement that contains no instructions.
If you get C4390 because of a macro, you should use the warning pragma to disable C4390 in the module containing the macro.
</description>
</rule>
<rule>
<key>C4391</key>
<configkey>C4391</configkey>
<priority>CRITICAL</priority>
<name>warning C4391: 'signature' : incorrect return type for intrinsic function, expected 'type'</name>
<description>
A function declaration for a compiler intrinsic had the wrong return type. The resulting image may not run correctly.
To fix this warning, either correct the declaration or delete the declaration and simply #include the appropriate header file.
</description>
</rule>
<rule>
<key>C4392</key>
<configkey>C4392</configkey>
<priority>CRITICAL</priority>
<name>warning C4392: 'signature' : incorrect number of arguments for intrinsic function, expected 'number' arguments</name>
<description>
A function declaration for a compiler intrinsic had the wrong number of arguments. The resulting image may not run correctly.
To fix this warning, either correct the declaration or delete the declaration and simply #include the appropriate header file.
</description>
</rule>
<rule>
<key>C4393</key>
<configkey>C4393</configkey>
<priority>CRITICAL</priority>
<name>warning C4393: 'var' : const has no effect on literal data member; ignored</name>
<description>
A literal data member was also specified as const. Since a literal data member implies const, you do not need to add const to the declaration.
</description>
</rule>
<rule>
<key>C4394</key>
<configkey>C4394</configkey>
<priority>CRITICAL</priority>
<name>warning C4394: 'function' : per-appdomain symbol should not be marked with __declspec(dllexport)</name>
<description>
A function marked with the appdomain __declspec modifier is compiled to MSIL (not to native), and export tables (export __declspec modifier) are not supported for managed functions.
You can declare a managed function to have public accessibility, see Type and Member Visibility for more information.
C4394 is always issued as an error. You can turn off this warning with the #pragma warning or /wd; see warning or /w, /Wn, /WX, /Wall, /wln, /wdn, /wen, /won (Warning Level) for more information.
</description>
</rule>
<rule>
<key>C4395</key>
<configkey>C4395</configkey>
<priority>CRITICAL</priority>
<name>warning C4395: 'function' : member function will be invoked on a copy of the initonly data member 'member'</name>
<description>
A member function was called on an initonly data member. C4395 warns that the initonly data member cannot be modified by the function.
</description>
</rule>
<rule>
<key>C4397</key>
<configkey>C4397</configkey>
<priority>CRITICAL</priority>
<name>warning C4397: DefaultCharSetAttribute is ignored</name>
<description>
DefaultCharSetAttribute is ignored by the Visual C++ compiler. To specify a character set for the DLL, use the CharSet option of DllImport. For more information, see Using C++ Interop (Implicit PInvoke).
</description>
</rule>
<rule>
<key>C4398</key>
<configkey>C4398</configkey>
<priority>CRITICAL</priority>
<name>warning C4398: 'variable' : per-process global object might not work correctly with multiple appdomains; consider using __declspec(appdomain)</name>
<description>
A virtual function with __clrcall calling convention in a native type causes the creation of a per application domain vtable. Such a variable may not correct correctly when used in multiple application domains.
You can resolve this warning by compiling with /clr:pure, which makes global variables per appdomain by default, or by explicitly marking the variable __declspec(appdomain).
For more information, see appdomain and Application Domains and Visual C++.
</description>
</rule>
<rule>
<key>C4399</key>
<configkey>C4399</configkey>
<priority>CRITICAL</priority>
<name>warning C4399: 'symbol' : per-process symbol should not be marked with __declspec(dllimport) when compiled with /clr:pure</name>
<description>
Data from a native image or an image with native and CLR constructs can not be imported into a pure image. To resolve this warning, compile with /clr (not /clr:pure) or delete __declspec(dllimport).
</description>
</rule>
<rule>
<key>C4400</key>
<configkey>C4400</configkey>
<priority>CRITICAL</priority>
<name>warning C4400: 'type' : const/volatile qualifiers on this type are not supported</name>
<description>
The const (C++)and volatile (C++)qualifiers will not work with variables of common language runtime types.
</description>
</rule>
<rule>
<key>C4401</key>
<configkey>C4401</configkey>
<priority>CRITICAL</priority>
<name>warning C4401: 'bitfield' : member is bit field</name>
<description>
Inline assembly code tries to access a bit-field member. Inline assembly cannot access bit-field members, so the last packing boundary before the bit-field member is used.
To avoid this warning, cast the bit field to an appropriate type before making the reference in inline assembly code.
</description>
</rule>
<rule>
<key>C4402</key>
<configkey>C4402</configkey>
<priority>CRITICAL</priority>
<name>warning C4402: must use PTR operator</name>
<description>
A type is used on an operand without a PTR operator when referring to or casting to a type in inline assembly code.
The compiler assumes the PTR operator.
</description>
</rule>
<rule>
<key>C4403</key>
<configkey>C4403</configkey>
<priority>CRITICAL</priority>
<name>warning C4403: illegal PTR operator</name>
<description>
A PTR operator is used inappropriately in inline assembler code.
The compiler ignored the PTR operator.
</description>
</rule>
<rule>
<key>C4404</key>
<configkey>C4404</configkey>
<priority>CRITICAL</priority>
<name>warning C4404: period on directive ignored</name>
<description>
The optional period preceding the directive is ignored.
</description>
</rule>
<rule>
<key>C4405</key>
<configkey>C4405</configkey>
<priority>CRITICAL</priority>
<name>warning C4405: 'identifier' : identifier is reserved word</name>
<description>
A word reserved for inline assembly is used as a variable name. This may cause unpredictable results. To fix this warning, avoid naming variables with words reserved for inline assembly.
</description>
</rule>
<rule>
<key>C4406</key>
<configkey>C4406</configkey>
<priority>CRITICAL</priority>
<name>warning C4406: operand on directive ignored</name>
<description>
The directive does not take any operands, but an operand was specified.
The compiler ignored the given operand or operands.
</description>
</rule>
<rule>
<key>C4407</key>
<configkey>C4407</configkey>
<priority>CRITICAL</priority>
<name>warning C4407: cast between different pointer to member representations, compiler may generate incorrect code</name>
<description>
An incorrect cast was detected.
C4407 can be generated because of compiler conformance work that was done in Visual C++ 2005. Pointer-to-member now requires a qualified name and the address-of operator (&).
C4407 can occur if you cast between a multiple inheritance pointer-to-member to a single inheritance pointer-to-member. Sometimes this can work, but sometimes it can’t because the single inheritance pointer-to-member representation doesn’t hold sufficient information. Compiling with the /vmm might help (for more information, see /vmm, /vms, /vmv (General Purpose Representation)). You can also try rearranging your base classes; the compiler is detecting a loss of information in the conversion because a base class is at a non-zero offset from the derived.
</description>
</rule>
<rule>
<key>C4408</key>
<configkey>C4408</configkey>
<priority>CRITICAL</priority>
<name>warning C4408: anonymous union did not declare any data members</name>
<description>
An anonymous union must have at least one data member.
</description>
</rule>
<rule>
<key>C4409</key>
<configkey>C4409</configkey>
<priority>CRITICAL</priority>
<name>warning C4409: illegal instruction size</name>
<description>
The instruction did not have a form with the specified size. The smallest legal size was used.
</description>
</rule>
<rule>
<key>C4410</key>
<configkey>C4410</configkey>
<priority>CRITICAL</priority>
<name>warning C4410: illegal size for operand</name>
<description>
One of the operands on the instruction had an incorrect size. The smallest legal size for the operand was used.
</description>
</rule>
<rule>
<key>C4411</key>
<configkey>C4411</configkey>
<priority>CRITICAL</priority>
<name>warning C4411: 'identifier' : symbol resolves to displacement register</name>
<description>
The identifier is a local symbol that resolves to a displacement register and therefore may be used on an operand with another symbol.
</description>
</rule>
<rule>
<key>C4412</key>
<configkey>C4412</configkey>
<priority>CRITICAL</priority>
<name>warning C4412: 'function' : function signature contains type 'type'; C++ objects are unsafe to pass between pure code and mixed or native.</name>
<description>
The compiler detected a potentially unsafe situation that could result in a runtime error: a call is being made from a /clr:pure compiland to a function that was imported via dllimport and the function signature contains an unsafe type. A type is unsafe if it contains a member function or has a data member that is an unsafe type or an indirection to an unsafe type.
This is unsafe because of the difference in the default calling conventions between pure and native code (or mixed native and managed). When importing (via dllimport) a function into a /clr:pure compiland, ensure that the declarations of each type in the signature are identical to those in the compiland that exports the function (being especially careful about differences in implicit calling conventions).
A virtual member function is especially prone to give unexpected results. However, even a non-virtual function should be tested to ensure that you get the correct results. If you are sure that you are getting the correct results, you can ignore this warning.
For more information on /clr:pure, see How to: Migrate to /clr:pure (C++/CLI).
C4412 is off by default. See Compiler Warnings That Are Off by Default and dllexport, dllimport for more information.
To resolve this warning, remove all functions from the type.
</description>
</rule>
<rule>
<key>C4414</key>
<configkey>C4414</configkey>
<priority>CRITICAL</priority>
<name>warning C4414: 'function' : short jump to function converted to near</name>
<description>
Short jumps generate compact instruction which branches to an address within a limited range from the instruction. The instruction includes a short offset that represents the distance between the jump and the target address, the function definition. During linking a function may be moved or subject to link-time optimizations that cause the function to be moved out of the range reachable from a short offset. The compiler must generate a special record for the jump, which requires the jmp instruction to be either NEAR or FAR. The compiler made the conversion.
</description>
</rule>
<rule>
<key>C4420</key>
<configkey>C4420</configkey>
<priority>CRITICAL</priority>
<name>warning C4420: 'operator' : operator not available, using 'operator' instead; run-time checking may be compromised</name>
<description>
This warning is generated when you use the /RTCv (vector new/delete checking) and when no vector form is found. In this case, the non-vector form is used.
In order for /RTCv to work correctly, the compiler should always call the vector form of new/delete if the vector syntax was used.
</description>
</rule>
<rule>
<key>C4428</key>
<configkey>C4428</configkey>
<priority>CRITICAL</priority>
<name>warning C4428: universal-character-name encountered in source</name>
<description>
The compiler issues C4428 when it detects at least one universal character name in a source code file. To fix this warning, use the Unicode equivalent of the universal character name.
This warning is only issued once per compiland.
</description>
</rule>
<rule>
<key>C4429</key>
<configkey>C4429</configkey>
<priority>CRITICAL</priority>
<name>warning C4429: possible incomplete or improperly formed universal-character-name</name>
<description>
The compiler detected a character sequence that may be a badly formed universal character name. A universal character name is \u followed by four hex digits, or \U followed by eight hex digits.
</description>
</rule>
<rule>
<key>C4430</key>
<configkey>C4430</configkey>
<priority>CRITICAL</priority>
<name>warning C4430: missing type specifier - int assumed. Note: C++ does not support default-int</name>
<description>
This error can be generated as a result of compiler conformance work that was done for Visual C++ 2005: all declarations must explicitly specify the type; int is no longer assumed.
C4430 is always issued as an error. You can turn off this warning with the #pragma warning or /wd; see warning or /w, /Wn, /WX, /Wall, /wln, /wdn, /wen, /won (Warning Level) for more information.
</description>
</rule>
<rule>
<key>C4431</key>
<configkey>C4431</configkey>
<priority>CRITICAL</priority>
<name>warning C4431: missing type specifier - int assumed. Note: C no longer supports default-int</name>
<description>
This error can be generated as a result of compiler conformance work that was done for Visual C++ 2005: Visual C++ no longer creates untyped identifiers as int by default. The type of an identifier must be specified explicitly.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4432</key>
<configkey>C4432</configkey>
<priority>CRITICAL</priority>
<name>warning C4432: a destructor in a ref-class must have public accessibility; changing to public access</name>
<description>
The compiler made a destructor public. To resolve this warning, explicitly put the destructor in a public section of the class.
For more information, see Destructors and Finalizers in Visual C++.
</description>
</rule>
<rule>
<key>C4433</key>
<configkey>C4433</configkey>
<priority>CRITICAL</priority>
<name>warning C4433: a finalizer must have protected accessibility; changing to protected access</name>
<description>
C4433 indicates that the compiler changed the accessibility of a finalizer. Finalizers must have protected accessibility. For more information, see Destructors and Finalizers in Visual C++.
</description>
</rule>
<rule>
<key>C4434</key>
<configkey>C4434</configkey>
<priority>CRITICAL</priority>
<name>warning C4434: a class constructor must have private accessibility; changing to private access</name>
<description>
C4434 indicates that the compiler changed the accessibility of a static constructor. Static constructors must have private accessibility, as they are only meant to be called by the common language runtime. For more information, see How to: Define Static Constructors in a Class or Struct.
</description>
</rule>
<rule>
<key>C4435</key>
<configkey>C4435</configkey>
<priority>CRITICAL</priority>
<name>warning C4435: 'class1' : Object layout under /vd2 will change due to virtual base 'class2'</name>
<description>
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
Under the default compile option of /vd1, the derived class does not have a vtordisp field for the indicated virtual base. If /vd2 or #pragma vtordisp(2) is in effect, a vtordisp field will be present, changing the object layout. This can lead to binary compatibility problems if interacting modules are compiled with different vtordisp settings.
</description>
</rule>
<rule>
<key>C4436</key>
<configkey>C4436</configkey>
<priority>CRITICAL</priority>
<name>warning C4436: dynamic_cast from virtual base 'class1' to 'class2' in constructor/destructor could fail with partially-constructed object Compile with /vd2 or define 'class2' with #pragma vtordisp(2)</name>
<description>
warning C4436: dynamic_cast from virtual base 'class1' to 'class2' in constructor or destructor could fail with partially-constructed object Compile with /vd2 or define 'class2' with #pragma vtordisp(2) in effect
The compiler has encountered a dynamic_cast operation with the following characteristics.
- The cast is from a base class pointer to a derived class pointer.
- The derived class virtually inherits the base class.
- The derived class does not have a vtordisp field for the virtual base.
- The cast is found in a constructor or destructor of the derived class, or some class which further inherits from the derived class.
The warning indicates the dynamic_cast might not perform correctly, if it is operating on a partially-constructed object. That happens if the derived constructor/destructor is operating on a sub-object of some further derived object. If the derived class named in the warning is never further derived, the warning can be ignored.
</description>
</rule>
<rule>
<key>C4437</key>
<configkey>C4437</configkey>
<priority>CRITICAL</priority>
<name>warning C4437: dynamic_cast from virtual base 'class1' to 'class2' could fail in some contexts Compile with /vd2 or define 'class2' with #pragma vtordisp(2) in effect</name>
<description>
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
The compiler has encountered a dynamic_cast operation with the following characteristics.
- The cast is from a base class pointer to a derived class pointer.
- The derived class virtually inherits the base class.
- The derived class does not have a vtordisp field for the virtual base.
- The cast is not found in a constructor or destructor of the derived class, or some class which further inherits from the derived class (otherwise, compiler warning C4436 will be issued).
The warning indicates that the dynamic_cast might not perform correctly if it is operating on a partially-constructed object. This situation occurs when the enclosing function is called from a constructor or destructor of a class that inherits the derived class that is named in the warning. If the derived class that is named in the warning is never further derived, or the enclosing function is not called during object construction or destruction, the warning can be ignored.
</description>
</rule>
<rule>
<key>C4439</key>
<configkey>C4439</configkey>
<priority>CRITICAL</priority>
<name>warning C4439: 'function' : function definition with a managed type in the signature must have a __clrcall calling convention</name>
<description>
The compiler implicitly replaced a calling convention with __clrcall. To resolve this warning, remove the __cdecl or __stdcall calling convention.
C4439 is always issued as an error. You can turn off this warning with the #pragma warning or /wd; see warning or /w, /Wn, /WX, /Wall, /wln, /wdn, /wen, /won (Warning Level) for more information.
</description>
</rule>
<rule>
<key>C4440</key>
<configkey>C4440</configkey>
<priority>CRITICAL</priority>
<name>warning C4440: calling convention redefinition from 'calling_convention1' to 'calling_convention2' ignored</name>
<description>
An attempt to change the calling convention was ignored.
</description>
</rule>
<rule>
<key>C4441</key>
<configkey>C4441</configkey>
<priority>CRITICAL</priority>
<name>warning C4441: calling convention of 'cc1' ignored; 'cc2' used instead</name>
<description>
Member functions in managed user-defined types and global function generics must use the __clrcall calling convention. The compiler used __clrcall.
</description>
</rule>
<rule>
<key>C4445</key>
<configkey>C4445</configkey>
<priority>CRITICAL</priority>
<name>warning C4445: 'function' : in a managed type a virtual method cannot be private</name>
<description>
If a virtual function is private, it cannot be accessed by a derived type.
</description>
</rule>
<rule>
<key>C4460</key>
<configkey>C4460</configkey>
<priority>CRITICAL</priority>
<name>warning C4460: CLR operator 'operator', has parameter passed by reference. CLR operator 'operator' has different semantics from C++ operator 'operator', did you intend to pass by value?</name>
<description>
You passed a value by reference to a user-defined CLR operator. If the value is changed inside the function, note that the value returned after the function call will be assigned the return value of the function. In standard C++, the changed value is reflected after the function call.
</description>
</rule>
<rule>
<key>C4461</key>
<configkey>C4461</configkey>
<priority>CRITICAL</priority>
<name>warning C4461: 'type' : this class has a finalizer 'finalizer' but no destructor 'dtor'</name>
<description>
The presence of a finalizer in a type implies resources to delete. Unless a finalizer is explicitly called from the type's destructor, the common language runtime determines when to run the finalizer, after your object goes out of scope.
If you define a destructor in the type and explicitly call the finalizer from the destructor, you can deterministically run your finalizer.
For more information, see Destructors and Finalizers in Visual C++.
</description>
</rule>
<rule>
<key>C4470</key>
<configkey>C4470</configkey>
<priority>CRITICAL</priority>
<name>warning C4470: floating-point control pragmas ignored under /clr</name>
<description>
The float-control pragmas:
- fenv_access
- float_control
- fp_contract
have no effect under /clr.
</description>
</rule>
<rule>
<key>C4480</key>
<configkey>C4480</configkey>
<priority>CRITICAL</priority>
<name>warning C4480: nonstandard extension used: specifying underlying type for enum 'enum'</name>
<description>
An extension to the language under /clr was used without /clr. You can disable C4480 with the warning pragma.
For more information, see /clr (Common Language Runtime Compilation), /Za, /Ze (Disable Language Extensions), enum class, and C++ Enumeration Declarations.
</description>
</rule>
<rule>
<key>C4481</key>
<configkey>C4481</configkey>
<priority>CRITICAL</priority>
<name>warning C4481: nonstandard extension used: override specifier 'keyword'</name>
<description>
A keyword was used that is not in the C++ standard, for example, one of the override specifiers that also works under /clr. For more information, see,
- /clr (Common Language Runtime Compilation)
- Override Specifiers
</description>
</rule>
<rule>
<key>C4482</key>
<configkey>C4482</configkey>
<priority>CRITICAL</priority>
<name>warning C4482: nonstandard extension used: enum 'enum' used in qualified name</name>
<description>
When you refer to an enum inside a type, you do not need to specify the name of the enum.
For more information on CLR enums, see enum class. For more information about native enums, see C++ Enumeration Declarations.
</description>
</rule>
<rule>
<key>C4484</key>
<configkey>C4484</configkey>
<priority>CRITICAL</priority>
<name>warning C4484: 'override_function' : matches base ref class method 'base_class_function', but is not marked 'virtual', 'new' or 'override'; 'new' (and not 'virtual') is assumed</name>
<description>
When compiling with /clr, the compiler will not implicitly override a base class function, which means the function will get a new slot in the vtable. To resolve, explicitly specify whether a function is an override.
For more information, see:
- /clr (Common Language Runtime Compilation)
- override
- new (new slot in vtable)
C4484 is always issued as an error. Use the warning pragma to suppress C4484.
</description>
</rule>
<rule>
<key>C4485</key>
<configkey>C4485</configkey>
<priority>CRITICAL</priority>
<name>warning C4485: 'override_function' : matches base ref class method 'base_class_function ', but is not marked 'new' or 'override'; 'new' (and 'virtual') is assumed</name>
<description>
An accessor overrides, with or without the virtual keyword, a base class accessor function, but the override or new specifier was not part of the overriding function signature. Add the new or override specifier to resolve this warning.
See override and new (new slot in vtable) for more information.
C4485 is always issued as an error. Use the warning pragma to suppress C4485.
</description>
</rule>
<rule>
<key>C4486</key>
<configkey>C4486</configkey>
<priority>CRITICAL</priority>
<name>warning C4486: 'function' : a private virtual method of a ref class or value class should be marked 'sealed'</name>
<description>
Since a private virtual member function of a managed class or struct cannot be accessed or overridden, it should be marked sealed.
</description>
</rule>
<rule>
<key>C4487</key>
<configkey>C4487</configkey>
<priority>CRITICAL</priority>
<name>warning C4487: 'derived_class_function' : matches inherited non-virtual method 'base_class_function' but is not explicitly marked 'new'</name>
<description>
A function in a derived class has the same signature as a non-virtual base class function. C4487 reminds you that the derived class function does not override the base class function. Explicitly mark the derived class function as new to resolve this warning.
</description>
</rule>
<rule>
<key>C4488</key>
<configkey>C4488</configkey>
<priority>CRITICAL</priority>
<name>warning C4488: 'function' : requires 'keyword' keyword to implement the interface method 'interface_method'</name>
<description>
A class must implement all members of an interface from which it directly inherits. An implemented member must have public accessibility, and must be marked virtual.
</description>
</rule>
<rule>
<key>C4489</key>
<configkey>C4489</configkey>
<priority>CRITICAL</priority>
<name>warning C4489: 'specifier' : not allowed on interface method 'method'; override specifiers are only allowed on ref class and value class methods</name>
<description>
A specifier keyword was incorrectly used on an interface method.
For more information, see Override Specifiers.
</description>
</rule>
<rule>
<key>C4490</key>
<configkey>C4490</configkey>
<priority>CRITICAL</priority>
<name>warning C4490: 'override' : incorrect use of override specifier; 'function' does not match a base ref class method</name>
<description>
An override specifier was used incorrectly. For example, you do not override an interface function, you implement it.
For more information, see Override Specifiers.
</description>
</rule>
<rule>
<key>C4502</key>
<configkey>C4502</configkey>
<priority>CRITICAL</priority>
<name>warning C4502: 'linkage specification' requires use of keyword 'extern' and must precede all other specifiers</name>
<description>
A linkage was specified without the extern keyword. Linkage is not relevant to non-extern types.
The compiler assumed the extern keyword.
</description>
</rule>
<rule>
<key>C4503</key>
<configkey>C4503</configkey>
<priority>CRITICAL</priority>
<name>warning C4503: 'identifier' : decorated name length exceeded, name was truncated</name>
<description>
The decorated name was longer than the compiler limit (4096), and was truncated. To avoid this warning and the truncation, reduce the number of arguments or name length of identifiers used.
One situation where this warning will be issued is when your code contains templates specialized on templates repeatedly. For example, a map of maps (from the Standard C++ Library). In this situation, you can make your typedefs a type (struct, for example) that contains the map.
You might, however, decide to not restructure your code. It is possible to ship an application that generates C4503, but if you get link time errors on a truncated symbol, it will be more difficult to determine the type of the symbol in the error. Debugging will also be more difficult; the debugger will also have difficultly mapping symbol name to type name. The correctness of the program, however, is unaffected by the truncated name.
</description>
</rule>
<rule>
<key>C4505</key>
<configkey>C4505</configkey>
<priority>CRITICAL</priority>
<name>warning C4505: 'function' : unreferenced local function has been removed</name>
<description>
The given function is local and not referenced in the body of the module; therefore, the function is dead code.
The compiler did not generate code for this dead function.
</description>
</rule>
<rule>
<key>C4506</key>
<configkey>C4506</configkey>
<priority>CRITICAL</priority>
<name>warning C4506: no definition for inline function 'function'</name>
<description>
The given function was declared and marked for inlining but was not defined.
The compiler did not inline the function.
Make sure that external functions to be inlined are declared with the extern keyword.
</description>
</rule>
<rule>
<key>C4508</key>
<configkey>C4508</configkey>
<priority>CRITICAL</priority>
<name>warning C4508: 'function' : function should return a value; 'void' return type assumed</name>
<description>
The function has no return type specified. In this case, C4430 should also fire and the compiler implements the fix reported by C4430 (default value is int).
To resolve this warning, explicitly declare the return type of functions.
</description>
</rule>
<rule>
<key>C4509</key>
<configkey>C4509</configkey>
<priority>CRITICAL</priority>
<name>warning C4509: nonstandard extension used: 'function' uses SEH and 'object' has destructor</name>
<description>
You should not use structured exception handling in functions that use objects with destructors. If an exception occurs, the destructor cannot be called. Use C++ exception handling instead.
</description>
</rule>
<rule>
<key>C4510</key>
<configkey>C4510</configkey>
<priority>CRITICAL</priority>
<name>warning C4510: 'class' : default constructor could not be generated</name>
<description>
The compiler cannot generate a default constructor for the specified class and no user-defined constructor was created. You will not be able to create objects of this type.
There are several situations that prevent the compiler from generating a default constructor, including:
- A const data member.
- A data member that is a reference.
You need to create a user-defined default constructor for the class that initializes these members.
</description>
</rule>
<rule>
<key>C4511</key>
<configkey>C4511</configkey>
<priority>CRITICAL</priority>
<name>warning C4511: 'class' : copy constructor could not be generated</name>
<description>
The compiler could not generate a default copy-constructor for a class; a base class may have a private copy-constructor.
</description>
</rule>
<rule>
<key>C4512</key>
<configkey>C4512</configkey>
<priority>CRITICAL</priority>
<name>warning C4512: 'class' : assignment operator could not be generated</name>
<description>
The compiler cannot generate an assignment operator for the given class. No assignment operator was created.
An assignment operator for the base class that is not accessible by the derived class can cause this warning.
To avoid this warning, specify a user-defined assignment operator for the class.
The compiler will also generate an assignment operator function for a class that does not define one. This assignment operator is a memberwise copy of the data members of an object. Because const data items cannot be modified after initialization, if the class contains a const item, the default assignment operator would not work. Another cause of the C4512 warning is a declaration of a nonstatic data member of reference type.
You can resolve the C4512 warning for your code in one of three ways:
- Explicitly define an assignment operator for the class.
- Remove const or the reference operator from the data item in the class.
- Use the #pragma warning statement to suppress the warning.
</description>
</rule>
<rule>
<key>C4513</key>
<configkey>C4513</configkey>
<priority>CRITICAL</priority>
<name>warning C4513: 'class' : destructor could not be generated</name>
<description>
The compiler cannot generate a default destructor for the given class; no destructor was created. The destructor is in a base class that is not accessible to the derived class. If the base class has a private destructor, make it public or protected.
</description>
</rule>
<rule>
<key>C4514</key>
<configkey>C4514</configkey>
<priority>CRITICAL</priority>
<name>warning C4514: 'function' : unreferenced inline function has been removedy</name>
<description>
The optimizer removed an inline function that is not called.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4515</key>
<configkey>C4515</configkey>
<priority>CRITICAL</priority>
<name>warning C4515: 'namespace' : namespace uses itself</name>
<description>
A namespace is used recursively.
</description>
</rule>
<rule>
<key>C4516</key>
<configkey>C4516</configkey>
<priority>CRITICAL</priority>
<name>warning C4516: 'class::symbol' : access-declarations are deprecated; member using-declarations provide a better alternative</name>
<description>
The ANSI C++ committee has declared access declarations (changing the access of a member in a derived class without the using keyword) to be outdated. Access declarations may not be supported by future versions of C++.
</description>
</rule>
<rule>
<key>C4517</key>
<configkey>C4517</configkey>
<priority>CRITICAL</priority>
<name>warning C4517: access-declarations are deprecated; member using-declarations provide a better alternative</name>
<description>
The ANSI C++ committee has declared access declarations (changing the access of a member in a derived class without the using keyword) to be outdated. Access declarations may not be supported by future versions of C++.
</description>
</rule>
<rule>
<key>C4518</key>
<configkey>C4518</configkey>
<priority>CRITICAL</priority>
<name>warning C4518: 'specifier' : storage-class or type specifier(s) unexpected here; ignored</name>
<description>
'specifier' : storage-class or type specifier(s) unexpected here; ignored
</description>
</rule>
<rule>
<key>C4519</key>
<configkey>C4519</configkey>
<priority>CRITICAL</priority>
<name>warning C4519: default template arguments are only allowed on a class template</name>
<description>
Default template arguments are allowed only on a class template declaration or definition. Default template arguments may not be used in a function template, or in the definition of a member of a class template.
</description>
</rule>
<rule>
<key>C4520</key>
<configkey>C4520</configkey>
<priority>CRITICAL</priority>
<name>warning C4520: 'class' : multiple default constructors specified</name>
<description>
The class has multiple default constructors. The first constructor is used.
</description>
</rule>
<rule>
<key>C4521</key>
<configkey>C4521</configkey>
<priority>CRITICAL</priority>
<name>warning C4521: 'class' : multiple copy constructors specified</name>
<description>
The class has multiple copy constructors of a single type. This warning is informational; the constructors are callable in your program.
Use the warning pragma to suppress this warning.
</description>
</rule>
<rule>
<key>C4522</key>
<configkey>C4522</configkey>
<priority>CRITICAL</priority>
<name>warning C4522: 'class' : multiple assignment operators specified</name>
<description>
The class has multiple assignment operators of a single type. This warning is informational; the constructors are callable in your program.
Use the warning pragma to suppress this warning.
</description>
</rule>
<rule>
<key>C4523</key>
<configkey>C4523</configkey>
<priority>CRITICAL</priority>
<name>warning C4523: 'class' : multiple destructors specified</name>
<description>
The class has multiple destructors.
</description>
</rule>
<rule>
<key>C4526</key>
<configkey>C4526</configkey>
<priority>CRITICAL</priority>
<name>warning C4526: 'function' : static member function cannot override virtual function 'virtual function'override ignored, virtual function will be hidden</name>
<description>
The static member function meets the criteria to override the virtual function, which makes the member function both virtual and static.
The following are possible fixes:
- If the function was intended to override the base class virtual function, remove the static specifier.
- If the function was intended to be a static member function, rename it so it doesn't conflict with the base class virtual function.
</description>
</rule>
<rule>
<key>C4530</key>
<configkey>C4530</configkey>
<priority>CRITICAL</priority>
<name>warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc </name>
<description>
When the /EHsc option has not been enabled, an object with automatic storage in the frame, between the function doing the throw and the function catching the throw, will not be destroyed. However, an object with automatic storage created in a try or catch block will be destroyed.
</description>
</rule>
<rule>
<key>C4532</key>
<configkey>C4532</configkey>
<priority>CRITICAL</priority>
<name>warning C4532: 'continue' : jump out of __finally/finally block has undefined behavior during termination handling</name>
<description>
The compiler encountered one of the following keywords:
- continue
- break
- goto
causing a jump out of a __finally or finally block during abnormal termination.
If an exception occurs, and while the stack is being unwound during execution of the termination handlers (the __finally or finally blocks), and your code jumps out of a __finally block before the __finally block ends, the behavior is undefined. Control may not return to the unwinding code, so the exception may not be handled properly.
If you must jump out of a __finally block, check for abnormal termination first.
The following sample generates C4532; simply comment out the jump statements to resolve the warnings.
</description>
</rule>
<rule>
<key>C4533</key>
<configkey>C4533</configkey>
<priority>CRITICAL</priority>
<name>warning C4533: initialization of 'variable' is skipped by 'instruction'</name>
<description>
An instruction in your program changed the flow of control, such that, an instruction that initialized a variable was not executed.
</description>
</rule>
<rule>
<key>C4534</key>
<configkey>C4534</configkey>
<priority>CRITICAL</priority>
<name>warning C4534: 'constructor' will not be a default constructor for class 'class' due to the default argument</name>
<description>
An unmanaged class can have a constructor with parameters that have default values and the compiler will use this as the default constructor. A class marked with the value keyword will not use a constructor with default values for its parameters as a default constructor.
For more information, see Classes and Structs (Platform).
</description>
</rule>
<rule>
<key>C4535</key>
<configkey>C4535</configkey>
<priority>CRITICAL</priority>
<name>warning C4535: calling _set_se_translator() requires /EHa</name>
<description>
The use of _set_se_translator requires the /EHa compiler option and not /EHs.
</description>
</rule>
<rule>
<key>C4536</key>
<configkey>C4536</configkey>
<priority>CRITICAL</priority>
<name>warning C4536: 'type name' : type-name exceeds meta-data limit of 'limit' characters</name>
<description>
A type name would be truncated in metadata if it was a managed type. See C3180 for more information.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4537</key>
<configkey>C4537</configkey>
<priority>CRITICAL</priority>
<name>warning C4537: 'object' : 'operator' applied to non-UDT type</name>
<description>
A reference was passed where an object (user-defined type) was expected. A reference is not an object, but inline assembler code is not able to make the distinction. The compiler generates code as though object were an instance.
</description>
</rule>
<rule>
<key>C4538</key>
<configkey>C4538</configkey>
<priority>CRITICAL</priority>
<name>warning C4538: 'type' : const/volatile qualifiers on this type are not supported</name>
<description>
A qualifier keyword was applied to an array incorrectly. For more information, see array.
</description>
</rule>
<rule>
<key>C4539</key>
<configkey>C4539</configkey>
<priority>CRITICAL</priority>
<name>warning C4539: 'char': a universal-character-name specifies an invalid character</name>
<description>
A character was specified out of Unicode range.
The character must be in the Unicode range, or be a valid surropate pair.
</description>
</rule>
<rule>
<key>C4540</key>
<configkey>C4540</configkey>
<priority>CRITICAL</priority>
<name>warning C4540: dynamic_cast used to convert to inaccessible or ambiguous base; run-time test will fail ('type1' to 'type2')</name>
<description>
You used dynamic_cast to convert from one type to another. The compiler determined that the cast would always fail (return NULL) because a base class is inaccessible (private, for instance) or ambiguous (appears more than once in the class hierarchy, for instance).
The following shows an example of this warning. Class B is derived from class A. The program uses dynamic_cast to cast from class B (the derived class) to class A, which will always fail because class B is private and thus inaccessible. Changing the access of A to public will resolve the warning.
</description>
</rule>
<rule>
<key>C4541</key>
<configkey>C4541</configkey>
<priority>CRITICAL</priority>
<name>warning C4541: 'identifier' used on polymorphic type 'type' with /GR-; unpredictable behavior may result</name>
<description>
You tried to use a feature that requires run-time type information without enabling run-time type information. Recompile with /GR.
</description>
</rule>
<rule>
<key>C4543</key>
<configkey>C4543</configkey>
<priority>CRITICAL</priority>
<name>warning C4543: Injected text suppressed by attribute 'no_injected_text'</name>
<description>
The no_injected_text attribute appeared in source code, which means the compiler will prevent attributes from injecting code.
This warning is to remind you that attributes will not be able to inject code.
</description>
</rule>
<rule>
<key>C4544</key>
<configkey>C4544</configkey>
<priority>CRITICAL</priority>
<name>warning C4544: Default arguments on template declaration ignored</name>
<description>
A default template argument was specified in an incorrect location and was ignored. A default template argument for a class template can only be specified in the declaration or definition of the class template and not on a member of the class template.
</description>
</rule>
<rule>
<key>C4545</key>
<configkey>C4545</configkey>
<priority>CRITICAL</priority>
<name>warning C4545: expression before comma evaluates to a function which is missing an argument list</name>
<description>
The compiler detected an ill-formed comma expression.
This warning is off by default. For more information, see Compiler Warnings That Are Off by Default.
</description>
</rule>
<rule>
<key>C4546</key>
<configkey>C4546</configkey>
<priority>CRITICAL</priority>
<name>warning C4546: function call before comma missing argument list</name>
<description>
The compiler detected an ill-formed comma expression.
This warning is off by default. For more information, see Compiler Warnings That Are Off by Default.
</description>
</rule>
<rule>
<key>C4547</key>
<configkey>C4547</configkey>
<priority>CRITICAL</priority>
<name>warning C4547: 'operator' : operator before comma has no effect; expected operator with side-effect</name>
<description>
The compiler detected an ill-formed comma expression.
This warning is off by default. For more information, see Compiler Warnings That Are Off by Default.
</description>
</rule>
<rule>
<key>C4548</key>
<configkey>C4548</configkey>
<priority>CRITICAL</priority>
<name>warning C4548: expression before comma has no effect; expected expression with side-effect</name>
<description>
The compiler detected an ill-formed comma expression.
This warning is off by default. For more information, see Compiler Warnings That Are Off by Default.
</description>
</rule>
<rule>
<key>C4549</key>
<configkey>C4549</configkey>
<priority>CRITICAL</priority>
<name>warning C4549: 'operator' : operator before comma has no effect; did you intend 'operator'?</name>
<description>
The compiler detected an ill-formed comma expression.
This warning is off by default. For more information, see Compiler Warnings That Are Off by Default.
</description>
</rule>
<rule>
<key>C4550</key>
<configkey>C4550</configkey>
<priority>CRITICAL</priority>
<name>warning C4550: expression evaluates to a function which is missing an argument list</name>
<description>
A dereferenced pointer to a function is missing an argument list.
</description>
</rule>
<rule>
<key>C4551</key>
<configkey>C4551</configkey>
<priority>CRITICAL</priority>
<name>warning C4551: function call missing argument list</name>
<description>
A function call must include the open and close parentheses after the function name even if the function takes no parameters.
</description>
</rule>
<rule>
<key>C4552</key>
<configkey>C4552</configkey>
<priority>CRITICAL</priority>
<name>warning C4552: 'operator' : operator has no effect; expected operator with side-effect</name>
<description>
If an expression statement has an operator with no side effect as the top of the expression, it's probably a mistake.
To override this warning, put the expression in parentheses.
</description>
</rule>
<rule>
<key>C4553</key>
<configkey>C4553</configkey>
<priority>CRITICAL</priority>
<name>warning C4553: 'operator' : operator has no effect; did you intend 'operator'?</name>
<description>
If an expression statement has an operator with no side effect as the top of the expression, it's probably a mistake.
</description>
</rule>
<rule>
<key>C4554</key>
<configkey>C4554</configkey>
<priority>CRITICAL</priority>
<name>warning C4554: 'operator' : check operator precedence for possible error; use parentheses to clarify precedence</name>
<description>
'operator' : check operator precedence for possible error; use parentheses to clarify precedence
</description>
</rule>
<rule>
<key>C4555</key>
<configkey>C4555</configkey>
<priority>CRITICAL</priority>
<name>warning C4555: expression has no effect; expected expression with side-effect</name>
<description>
This warning informs you when an expression has no effect.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4556</key>
<configkey>C4556</configkey>
<priority>CRITICAL</priority>
<name>warning C4556: value of intrinsic immediate argument 'value' is out of range 'lowerbound - upperbound'</name>
<description>
An intrinsic matches a hardware instruction. The hardware instruction has a fixed number of bits to encode the constant. If value is out of range, it will not encode properly. The compiler truncates the extra bits.
</description>
</rule>
<rule>
<key>C4557</key>
<configkey>C4557</configkey>
<priority>CRITICAL</priority>
<name>warning C4557: '__assume' contains effect 'effect'</name>
<description>
The value passed to an __assume statement2 was modified.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4558</key>
<configkey>C4558</configkey>
<priority>CRITICAL</priority>
<name>warning C4558: value of operand 'value' is out of range 'lowerbound - upperbound'</name>
<description>
The value passed to an assembly language instruction is out of the range specified for the parameter. The value will be truncated.
</description>
</rule>
<rule>
<key>C4559</key>
<configkey>C4559</configkey>
<priority>CRITICAL</priority>
<name>warning C4559: 'function' : redefinition; the function gains __declspec(modifier)</name>
<description>
A function was redefined or redeclared and the second definition or declaration added a __declspec modifier (modifier). This warning is informational. To fix this warning, delete one of the definitions.
</description>
</rule>
<rule>
<key>C4561</key>
<configkey>C4561</configkey>
<priority>CRITICAL</priority>
<name>warning C4561: '__fastcall' incompatible with the '/clr' option: converting to '__stdcall'</name>
<description>
The __fastcall function-calling convention cannot be used with the /clr compiler option. The compiler ignores the calls to __fastcall. To fix this warning, either remove the calls to __fastcall or compile without /clr.
</description>
</rule>
<rule>
<key>C4564</key>
<configkey>C4564</configkey>
<priority>CRITICAL</priority>
<name>warning C4564: method 'method' of class 'class' defines unsupported default parameter 'parameter'</name>
<description>
The compiler detected a method with one or more parameters with default values. The default value(s) for the parameters will be ignored when the method is invoked; explicitly specify values for those parameters. If you do not explicitly specify values for those parameters, the C++ compiler will generate an error.
</description>
</rule>
<rule>
<key>C4565</key>
<configkey>C4565</configkey>
<priority>CRITICAL</priority>
<name>warning C4565: 'function' : redefinition; the symbol was previously declared with __declspec(modifier)</name>
<description>
A symbol was redefined or redeclared and the second definition or declaration, unlike the first definition or declaration, did not have a __declspec modifier (modifier). This warning is informational. To fix this warning, delete one of the definitions.
</description>
</rule>
<rule>
<key>C4566</key>
<configkey>C4566</configkey>
<priority>CRITICAL</priority>
<name>warning C4566: character represented by universal-character-name 'char' cannot be represented in the current code page (page)</name>
<description>
Not every Unicode character can be represented in your current ANSI code page.
Narrow strings (one-byte characters) are converted to multi-byte characters whereas wide strings (two-byte characters) are not.
</description>
</rule>
<rule>
<key>C4570</key>
<configkey>C4570</configkey>
<priority>CRITICAL</priority>
<name>warning C4570: 'type' : is not explicitly declared as abstract but has abstract functions</name>
<description>
A type that contains abstract (Visual C++) functions should itself be marked as abstract.
</description>
</rule>
<rule>
<key>C4571</key>
<configkey>C4571</configkey>
<priority>CRITICAL</priority>
<name>warning C4571: Informational: catch(...) semantics changed since Visual C++ 7.1; structured exceptions (SEH) are no longer caught</name>
<description>
C4571 is generated for every catch(...) block when compiling with /EHs.
When compiling with /EHs, a catch(...) block will not catch a structured exception (divide by zero, null pointer, for example); a catch(...) block will only catch explicitly-thrown, C++ exceptions. For more information, see Exception Handling in Visual C++.
This warning is off by default. Turn this warning on to ensure that when you compile with /EHs your catch (...) blocks do not intend to catch structured exceptions. See Compiler Warnings That Are Off by Default for more information.
You can resolve C4571 in one of the following ways,
- Compile with /EHa if you still want your catch(...) blocks to catch structured exceptions.
- Do not enable C4571 if you do not want your catch(...) blocks to catch structured exceptions, but you still want to use catch(...) blocks. You can still catch structured exceptions using the structured exception handling keywords (__try, __except, and __finally). But remember, when compiled /EHs destructors will only be called when a C++ exception is thrown, not when an SEH exception occurs.
- Replace catch(...) block with catch blocks for specific C++ exceptions, and optionally, add structured exception handling around the C++ exception handling (__try, __except, and __finally). See Structured Exception Handling (C++) for more information.
See /EH (Exception Handling Model) for more information.
</description>
</rule>
<rule>
<key>C4572</key>
<configkey>C4572</configkey>
<priority>CRITICAL</priority>
<name>warning C4572: [ParamArray] attribute is deprecated under /clr, use '...' instead</name>
<description>
An obsolete style for specifying a variable argument list was used. When compiling for the CLR, use ellipsis syntax instead of ParamArrayAttribute. For more information, see Variable Argument Lists (...).
</description>
</rule>
<rule>
<key>C4580</key>
<configkey>C4580</configkey>
<priority>CRITICAL</priority>
<name>warning C4580: [attribute] is deprecated; instead specify System::Attribute as a base class</name>
<description>
attribute is no longer the preferred syntax for creating user-defined attributes. For more information, see User-Defined Attributes.
</description>
</rule>
<rule>
<key>C4581</key>
<configkey>C4581</configkey>
<priority>CRITICAL</priority>
<name>warning C4581: deprecated behavior: '"string1"' replaced with 'string2' to process attribute</name>
<description>
This error can be generated as a result of compiler conformance work that was done for Visual C++ 2005: parameter checking for Visual C++ attributes.
In previous versions, attribute values were accepted whether or not they were enclosed in quotation marks. If the value is an enumeration, it must not be enclosed in quotation marks.
</description>
</rule>
<rule>
<key>C4584</key>
<configkey>C4584</configkey>
<priority>CRITICAL</priority>
<name>warning C4584: 'class1' : base-class 'class2' is already a base-class of 'class3'</name>
<description>
The class you defined inherits from two classes, one of which inherits from the other.
</description>
</rule>
<rule>
<key>C4600</key>
<configkey>C4600</configkey>
<priority>CRITICAL</priority>
<name>warning C4600: #pragma 'macro name' : expected a valid non-empty string</name>
<description>
You cannot specify an empty string when you push or pop a macro name with either the pop_macro or push_macro.
</description>
</rule>
<rule>
<key>C4606</key>
<configkey>C4606</configkey>
<priority>CRITICAL</priority>
<name>warning C4606: #pragma warning : 'warning_number' ignored; Code Analysis warnings are not associated with warning levels</name>
<description>
For Code Analysis warnings, only error, once, and default are supported with the warning pragma.
</description>
</rule>
<rule>
<key>C4610</key>
<configkey>C4610</configkey>
<priority>CRITICAL</priority>
<name>warning C4610: object 'class' can never be instantiated - user-defined constructor required</name>
<description>
The class has no user-defined or default constructors. No instantiation is performed
</description>
</rule>
<rule>
<key>C4611</key>
<configkey>C4611</configkey>
<priority>CRITICAL</priority>
<name>warning C4611: interaction between 'function' and C++ object destruction is non-portable</name>
<description>
On some platforms, functions that include catch may not support C++ object semantics of destruction when out of scope.
To avoid unexpected behavior, avoid using catch in functions that have constructors and destructors.
This warning is only issued once; see pragma warning.
</description>
</rule>
<rule>
<key>C4615</key>
<configkey>C4615</configkey>
<priority>CRITICAL</priority>
<name>warning C4615: #pragma warning : unknown user warning type</name>
<description>
An invalid warning specifier was used with pragma warning. To resolve the error, use a valid warning specifier.
</description>
</rule>
<rule>
<key>C4616</key>
<configkey>C4616</configkey>
<priority>CRITICAL</priority>
<name>warning C4616: #pragma warning : warning number 'number' not a valid compiler warning</name>
<description>
The warning number specified in the warning pragma cannot be reassigned. The pragma was ignored.
</description>
</rule>
<rule>
<key>C4618</key>
<configkey>C4618</configkey>
<priority>CRITICAL</priority>
<name>warning C4618: pragma parameters included an empty string; pragma ignored</name>
<description>
A null string was given as an argument to a #pragma.
The pragma was processed without the argument.
</description>
</rule>
<rule>
<key>C4619</key>
<configkey>C4619</configkey>
<priority>CRITICAL</priority>
<name>warning C4619: #pragma warning : there is no warning number 'number'</name>
<description>
An attempt was made to disable a warning that does not exist.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4621</key>
<configkey>C4621</configkey>
<priority>CRITICAL</priority>
<name>warning C4621: no postfix form of 'operator -' found for type 'type', using prefix form</name>
<description>
There was no postfix decrement operator defined for the given type. The compiler used the overloaded prefix operator.
This warning can be avoided by defining a postfix - operator.
</description>
</rule>
<rule>
<key>C4623</key>
<configkey>C4623</configkey>
<priority>CRITICAL</priority>
<name>warning C4623: 'derived class' : default constructor could not be generated because a base class default constructor is inaccessible</name>
<description>
A constructor was not accessible in a base class and was therefore not generated for a derived class. Any attempt to create an object of this type on the stack will cause a compiler error.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4624</key>
<configkey>C4624</configkey>
<priority>CRITICAL</priority>
<name>warning C4624: 'derived class' : destructor could not be generated because a base class destructor is inaccessible</name>
<description>
A destructor was not accessible in a base class and was therefore not generated for a derived class. Any attempt to create an object of this type on the stack will cause a compiler error.
</description>
</rule>
<rule>
<key>C4625</key>
<configkey>C4625</configkey>
<priority>CRITICAL</priority>
<name>warning C4625: 'derived class' : copy constructor could not be generated because a base class copy constructor is inaccessible</name>
<description>
A copy constructor was not accessible in a base class and was therefore not generated for a derived class. Any attempt to copy an object of this type will cause a compiler error.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4626</key>
<configkey>C4626</configkey>
<priority>CRITICAL</priority>
<name>warning C4626: 'derived class' : assignment operator could not be generated because a base class assignment operator is inaccessible</name>
<description>
An assignment operator was not accessible in a base class and was therefore not generated for a derived class. Any attempt to assign objects of this type will cause a compiler error.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4627</key>
<configkey>C4627</configkey>
<priority>CRITICAL</priority>
<name>warning C4627: '<identifier>': skipped when looking for precompiled header use</name>
<description>
While searching for the location where a precompiled header is used, the compiler encountered an #include directive for the <identifier> include file. The compiler ignores the #include directive, but issues warning C4627 if the precompiled header does not already contain the <identifier> include file.
</description>
</rule>
<rule>
<key>C4628</key>
<configkey>C4628</configkey>
<priority>CRITICAL</priority>
<name>warning C4628: digraphs not supported with -Ze. Character sequence 'digraph' not interpreted as alternate token for 'char'</name>
<description>
Digraphs are not supported under /Ze. This warning will be followed by an error.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4630</key>
<configkey>C4630</configkey>
<priority>CRITICAL</priority>
<name>warning C4630: 'symbol' : 'extern' storage class specifier illegal on member definition</name>
<description>
A data member or member function is defined as extern. Members cannot be external, although entire objects can. The compiler ignores the extern keyword.
</description>
</rule>
<rule>
<key>C4632</key>
<configkey>C4632</configkey>
<priority>CRITICAL</priority>
<name>warning C4632: XML document comment: file - access denied: reason</name>
<description>
The path to .xdc file (file) was not valid, and no .xdc file created.
</description>
</rule>
<rule>
<key>C4633</key>
<configkey>C4633</configkey>
<priority>CRITICAL</priority>
<name>warning C4633: XML document comment target - error</name>
<description>
A name passed to the <param> tag was not found by the compiler.
</description>
</rule>
<rule>
<key>C4639</key>
<configkey>C4639</configkey>
<priority>CRITICAL</priority>
<name>warning C4639: MSXML error, XML document comments will not be processed.</name>
<description>
This warning can occur for any number of reasons.
To resolve this warning:
- Recompile.
- Reinstall MSXML by reinstalling the common language runtime.
- Edit or remove the documentation comment that is causing the warning and recompile.
When C4639 is issued, all further XML comment processing is disabled, and the .xdc file is not generated.
</description>
</rule>
<rule>
<key>C4640</key>
<configkey>C4640</configkey>
<priority>CRITICAL</priority>
<name>warning C4640: 'instance' : construction of local static object is not thread-safe</name>
<description>
A static instance of an object is not thread safe.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4641</key>
<configkey>C4641</configkey>
<priority>CRITICAL</priority>
<name>warning C4641: XML document comment has an ambiguous cross reference</name>
<description>
The compiler was unable to unambiguously resolve a reference. To resolve this warning, specify the parameter information necessary to make the reference unambiguous.
</description>
</rule>
<rule>
<key>C4650</key>
<configkey>C4650</configkey>
<priority>CRITICAL</priority>
<name>warning C4650: debugging information not in precompiled header; only global symbols from the header will be available</name>
<description>
The precompiled header file was not compiled with Microsoft symbolic debugging information.
When linked, the resulting executable or dynamic-link library file will not include debugging information for local symbols contained in the precompiled header.
This warning can be avoided by recompiling the precompiled header file with the /Zi command-line option.
</description>
</rule>
<rule>
<key>C4651</key>
<configkey>C4651</configkey>
<priority>CRITICAL</priority>
<name>warning C4651: 'definition' specified for precompiled header but not for current compile</name>
<description>
The definition was specified when the precompiled header was generated, but not in this compilation.
The definition will be in effect inside the precompiled header, but not in the rest of the code.
If a precompiled header was built with /DSYMBOL, the compiler will generate this warning if the /Yu compile doesn't have /DSYMBOL. Adding /DSYMBOL to the /Yu command line resolves this warning.
</description>
</rule>
<rule>
<key>C4652</key>
<configkey>C4652</configkey>
<priority>CRITICAL</priority>
<name>warning C4652: compiler option 'option' inconsistent with precompiled header; current command-line option will override that defined in the precompiled header</name>
<description>
The given command-line option differed from that given when the precompiled header (.pch) was created. The option specified in the current command line was used.
This warning can be avoided by regenerating the precompiled header with the given command-line option.
</description>
</rule>
<rule>
<key>C4653</key>
<configkey>C4653</configkey>
<priority>CRITICAL</priority>
<name>warning C4653: compiler option 'option' inconsistent with precompiled header; current command-line option ignored</name>
<description>
An option specified with the Use Precompiled Headers (/Yu) option was inconsistent with the options specified when the precompiled header was created. This compilation used the option specified when the precompiled header was created.
This warning can occur when a different value for the Pack Structures option (/Zp) was specified during compilation of the precompiled header.
</description>
</rule>
<rule>
<key>C4656</key>
<configkey>C4656</configkey>
<priority>CRITICAL</priority>
<name>warning C4656: 'symbol' : data type is new or has changed since the last build, or is defined differently elsewhere</name>
<description>
You added or changed a data type, making it new to your source code since the last successful build. Edit and Continue does not support changes to existing data types.
This warning will always be followed by Fatal Error C1092. For further information, see the Supported Code Changes.
To remove this warning without ending the current debug session
- Change the data type back to its state prior to the error.
- From the Debug menu, choose Apply Code Changes.
To remove this error without changing your source code
- From the Debug menu, choose Stop Debugging.
- From the Build menu, choose Build.
</description>
</rule>
<rule>
<key>C4659</key>
<configkey>C4659</configkey>
<priority>CRITICAL</priority>
<name>warning C4659: #pragma 'pragma' : use of reserved segment 'segment' has undefined behavior, use #pragma comment(linker, ...)</name>
<description>
The .drectve option was used to pass an option to the linker. Instead use pragma comment for passing a linker option.
</description>
</rule>
<rule>
<key>C4661</key>
<configkey>C4661</configkey>
<priority>CRITICAL</priority>
<name>warning C4661: 'identifier' : no suitable definition provided for explicit template instantiation request</name>
<description>
A member of the template class is not defined.
</description>
</rule>
<rule>
<key>C4667</key>
<configkey>C4667</configkey>
<priority>CRITICAL</priority>
<name>warning C4667: 'function' : no function template defined that matches forced instantiation</name>
<description>
You cannot instantiate a function template that has not been declared.
</description>
</rule>
<rule>
<key>C4668</key>
<configkey>C4668</configkey>
<priority>CRITICAL</priority>
<name>warning C4668: 'symbol' is not defined as a preprocessor macro, replacing with '0' for 'directives'</name>
<description>
A symbol that was not defined was used with a preprocessor directive. The symbol will evaluate to false. To define a symbol, you can use either the #define directive or /D compiler option.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4673</key>
<configkey>C4673</configkey>
<priority>CRITICAL</priority>
<name>warning C4673: throwing 'identifier' the following types will not be considered at the catch site</name>
<description>
A throw object cannot be handled in the catch block. Each type that cannot be handled is listed in the error output immediately following the line containing this warning. Each unhandled type has its own warning. Read the warning for each specific type for more information.
</description>
</rule>
<rule>
<key>C4677</key>
<configkey>C4677</configkey>
<priority>CRITICAL</priority>
<name>warning C4677: 'function': signature of non-private member contains assembly private type 'private_type'</name>
<description>
A type that has public accessibility outside the assembly uses a type that has private access outside the assembly. A component that references the public assembly type will not be able to use the type member or members that reference the assembly private type.
</description>
</rule>
<rule>
<key>C4679</key>
<configkey>C4679</configkey>
<priority>CRITICAL</priority>
<name>warning C4679: The compiler encountered a construct that it cannot support, that cannot be imported from metadata.</name>
<description>
'member': could not import member
Do not try to use the construct.
</description>
</rule>
<rule>
<key>C4680</key>
<configkey>C4680</configkey>
<priority>CRITICAL</priority>
<name>warning C4680: 'class': coclass does not specify a default interface</name>
<description>
A default interface was not specified for a class that was marked with the coclass attribute. In order for an object to be useful, it must implement an interface.
</description>
</rule>
<rule>
<key>C4683</key>
<configkey>C4683</configkey>
<priority>CRITICAL</priority>
<name>warning C4683: 'function': event source has an 'out'-parameter; exercise caution when hooking multiple event handlers</name>
<description>
If more than one event sink is listening to a COM event source, the value of an out parameter may be ignored.
Be aware that a memory leak will occur in the following situation:
- If a method has an out parameter that is internally allocated, for example a BSTR *.
- If the event has more than one handler (is a multicast event)
The reason for the leak is that the out parameter will be set by more than one handler, but returned to the call site only by the last handler.
</description>
</rule>
<rule>
<key>C4684</key>
<configkey>C4684</configkey>
<priority>CRITICAL</priority>
<name>warning C4684: 'attribute' : WARNING!! attribute may cause invalid code generation: use with caution</name>
<description>
You used an attribute that should not commonly be used.
</description>
</rule>
<rule>
<key>C4686</key>
<configkey>C4686</configkey>
<priority>CRITICAL</priority>
<name>warning C4686: 'user-defined type' : possible change in behavior, change in UDT return calling convention</name>
<description>
A class template specialization was not is defined before it was used in a return type. Anything that instantiates the class will resolve C4686; declaring an instance or accessing a member (C<int>::anything) are also options.
This warning is the result of work to make the Visual C++ .NET 2003 compiler conform to the ISO C++ standard.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4687</key>
<configkey>C4687</configkey>
<priority>CRITICAL</priority>
<name>warning C4687: 'class': a sealed abstract class cannot implement an interface 'interface'</name>
<description>
A sealed, abstract type is typically only useful to hold static member functions.
For more information, see abstract (Visual C++)and sealed.
C4687 is issued as an error by default. You can suppress C4687 with the warning pragma. If you are certain that you want to implement an interface in a sealed, abstract type, you can suppress C4687.
</description>
</rule>
<rule>
<key>C4691</key>
<configkey>C4691</configkey>
<priority>CRITICAL</priority>
<name>warning C4691: 'type' : type referenced was expected in unreferenced assembly 'file', type defined in current translation unit used instead</name>
<description>
The metadata file containing the original type definition is not referenced, and the compiler is using a local type definition.
In the case where you are rebuilding file, C4691 can be ignored or turned off with pragma warning. That is, if the file you are building is the same as the file where the compiler expects to find the type definition, you can ignore C4691.
However, unexpected behavior can occur if the compiler uses a definition that is not from the same assembly that is referenced in metadata; CLR types are typed not only by the name of the type, but also by the assembly. That is, a type Z from assembly z.dll is different from a type Z from assembly y.dll
</description>
</rule>
<rule>
<key>C4692</key>
<configkey>C4692</configkey>
<priority>CRITICAL</priority>
<name>warning C4692: 'function': signature of non-private member contains assembly private native type 'native_type'</name>
<description>
A type that is visible outside the assembly contains a member function whose signature contains a native type that is not visible outside the assembly. Therefore, the member function should not be called if its containing type is instantiated outside the assembly.
For more information, see Type Visibility.
This warning is off by default. For more information, see Compiler Warnings That Are Off by Default.
</description>
</rule>
<rule>
<key>C4700</key>
<configkey>C4700</configkey>
<priority>CRITICAL</priority>
<name>warning C4700: uninitialized local variable 'name' used</name>
<description>
You used the local variable name without first assigning it a value, which could lead to unpredictable results.
</description>
</rule>
<rule>
<key>C4701</key>
<configkey>C4701</configkey>
<priority>CRITICAL</priority>
<name>warning C4701: Potentially uninitialized local variable 'name' used</name>
<description>
The local variable name might have been used without being assigned a value. This could lead to unpredictable results.
</description>
</rule>
<rule>
<key>C4702</key>
<configkey>C4702</configkey>
<priority>CRITICAL</priority>
<name>warning C4702: unreachable code</name>
<description>
This warning is the result of compiler conformance work that was done for Visual Studio .NET 2003: unreachable code. When the compiler (back end) detects unreachable code, it will generate C4702, a level 4 warning.
For code that is valid in both the Visual Studio .NET 2003 and Visual Studio .NET versions of Visual C++, remove the unreachable code or assure that all source code is reachable by some flow of execution.
</description>
</rule>
<rule>
<key>C4703</key>
<configkey>C4703</configkey>
<priority>CRITICAL</priority>
<name>warning C4703: Potentially uninitialized local pointer variable 'name' used</name>
<description>
The local pointer variable name might have been used without being assigned a value. This could lead to unpredictable results.
</description>
</rule>
<rule>
<key>C4706</key>
<configkey>C4706</configkey>
<priority>CRITICAL</priority>
<name>warning C4706: assignment within conditional expression</name>
<description>
The test value in a conditional expression was the result of an assignment.
An assignment has a value (the value on the left side of the assignment) that can be used legally in another expression, including a test expression.
</description>
</rule>
<rule>
<key>C4709</key>
<configkey>C4709</configkey>
<priority>CRITICAL</priority>
<name>warning C4709: comma operator within array index expression</name>
<description>
When a comma occurs in an array index expression, the compiler uses the value after the last comma.
</description>
</rule>
<rule>
<key>C4710</key>
<configkey>C4710</configkey>
<priority>CRITICAL</priority>
<name>warning C4710: 'function' : function not inlined</name>
<description>
The given function was selected for inline expansion, but the compiler did not perform the inlining.
Inlining is performed at the compiler's discretion. The inline keyword, like the register keyword, is used as a hint for the compiler. The compiler uses heuristics to determine if it should inline a particular function to speed up the code when compiling for speed, or if it should inline a particular function to make the code smaller when compiling for space. The compiler will only inline very small functions when compiling for space.
In some cases, the compiler will not inline a particular function for mechanical reasons. See C4714 for a list of reasons the compiler may not inline a function.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4711</key>
<configkey>C4711</configkey>
<priority>CRITICAL</priority>
<name>warning C4711: function 'function' selected for inline expansion</name>
<description>
The compiler performed inlining on the given function, although it was not marked for inlining.
C4711 is enabled if /Ob2 is specified.
Inlining is performed at the compiler's discretion. This warning is informational.
This warning is off by default. To enable a warning, use #pragma warning. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4714</key>
<configkey>C4714</configkey>
<priority>CRITICAL</priority>
<name>warning C4714: function 'function' marked as __forceinline not inlined</name>
<description>
The given function was selected for inline expansion, but the compiler did not perform the inlining.
Although __forceinline is a stronger indication to the compiler than __inline, inlining is still performed at the compiler's discretion, but no heuristics are used to determine the benefits from inlining this function.
In some cases, the compiler will not inline a particular function for mechanical reasons. For example, the compiler will not inline:
- A function if it would result in mixing both SEH and C++ EH.
- Some functions with copy constructed objects passed by value when -GX/EHs/EHa is on.
- Functions returning an unwindable object by value when -GX/EHs/EHa is on.
- Functions with inline assembly when compiling without -Og/Ox/O1/O2.
- Functions with a variable argument list.
- A function with a try (C++ exception handling) statement.
</description>
</rule>
<rule>
<key>C4715</key>
<configkey>C4715</configkey>
<priority>CRITICAL</priority>
<name>warning C4715: 'function' : not all control paths return a value</name>
<description>
The specified function can potentially not return a value.
</description>
</rule>
<rule>
<key>C4716</key>
<configkey>C4716</configkey>
<priority>CRITICAL</priority>
<name>warning C4716: 'function' must return a value</name>
<description>
The given function did not return a value.
Only functions with a return type of void can use the return command without an accompanying return value.
An undefined value will be returned when this function is called.
This warning is automatically promoted to an error. If you wish to modify this behavior, use #pragma warning.
</description>
</rule>
<rule>
<key>C4717</key>
<configkey>C4717</configkey>
<priority>CRITICAL</priority>
<name>warning C4717: 'function' : recursive on all control paths, function will cause runtime stack overflow</name>
<description>
Every path through a function contains a call to the function. Since there is no way to exit the function without first calling itself recursively, the function will never exit.
</description>
</rule>
<rule>
<key>C4723</key>
<configkey>C4723</configkey>
<priority>CRITICAL</priority>
<name>warning C4723: potential divide by 0</name>
<description>
The second operand in a divide operation evaluated to zero at compile time, giving undefined results.
This warning is issued only when using /Og or an optimization option that implies /Og.
The compiler may have generated the zero operand.
</description>
</rule>
<rule>
<key>C4727</key>
<configkey>C4727</configkey>
<priority>CRITICAL</priority>
<name>warning C4727: "PCH named pch_file with same timestamp found in obj_file_1 and obj_file_2. Using first PCH.</name>
<description>
C4727 occurs when compiling multiple compilands with /Yc, and where the compiler was able to mark all .obj files with the same .pch timestamp.
To resolve, compile one source file with /Yc /c (creates pch), and the others compile separately with /Yu /c (uses pch), then link them together.
So, if you did the following and generates C4727:
- cl /clr /GL a.cpp b.cpp c.cpp /Ycstdafx.h
You would do the following instead:
- cl /clr /GL a.cpp /Ycstdafx.h /c
- cl /clr /GL b.cpp c.cpp /Yustdafx.h /link a.obj
For more information, see
- /Yc (Create Precompiled Header File)
- /Yu (Use Precompiled Header File)
</description>
</rule>
<rule>
<key>C4730</key>
<configkey>C4730</configkey>
<priority>CRITICAL</priority>
<name>warning C4730: 'main' : mixing _m64 and floating point expressions may result in incorrect code</name>
<description>
A function uses __m64 and float/double types. Because the MMX and floating-point registers share the same physical register space (cannot be used simultaneously), using __m64 and float/double types in the same function can result in data corruption, possibly causing an exception.
To safely use __m64 types and floating-point types in the same function, each instruction that uses one of the types should be separated by the _m_empty() (for MMX) or _m_femms() (for 3DNow!) intrinsic.
</description>
</rule>
<rule>
<key>C4731</key>
<configkey>C4731</configkey>
<priority>CRITICAL</priority>
<name>warning C4731: 'pointer' : frame pointer register 'register' modified by inline assembly code</name>
<description>
A frame pointer register was modified. You must save and restore the register in your inline assembly block or frame variable (local or parameter, depending on the register modified), or your code may not work properly.
</description>
</rule>
<rule>
<key>C4733</key>
<configkey>C4733</configkey>
<priority>CRITICAL</priority>
<name>warning C4733: Inline asm assigning to 'FS:0' : handler not registered as safe handler</name>
<description>
A function modifying the value at FS:0 to add a new exception handler may not work with Safe Exceptions, because the handler may not be registered as a valid exception handler (see /SAFESEH).
To resolve this warning, either remove the FS:0 definition or turn off this warning and use .SAFESEH to specify the safe exception handlers.
</description>
</rule>
<rule>
<key>C4738</key>
<configkey>C4738</configkey>
<priority>CRITICAL</priority>
<name>warning C4738: storing 32-bit float result in memory, possible loss of performance</name>
<description>
C4738 warns that the result of an assignment, cast, passed argument, or other operation may need to be rounded or that the operation ran out of registers and needed to use memory (spilling). This can result in performance loss.
To resolve this warning and avoid rounding, compile with /fp:fast or use doubles instead of floats.
To resolve this warning and avoid running out of registers, change the order of computation and modify your use of inlining
This warning is off by default. For more information, see Compiler Warnings That Are Off by Default.
</description>
</rule>
<rule>
<key>C4740</key>
<configkey>C4740</configkey>
<priority>CRITICAL</priority>
<name>warning C4740: flow in or out of inline asm code suppresses global optimization</name>
<description>
When there is a jump in to or out of an asm block, global optimizations are disabled for that function.
</description>
</rule>
<rule>
<key>C4742</key>
<configkey>C4742</configkey>
<priority>CRITICAL</priority>
<name>warning C4742: 'var' has different alignment in 'file1' and 'file2': number and number</name>
<description>
An external variable that was referenced or defined in two files has different alignment in those files. This warning is emitted when compiler finds that __alignof for the variable in file1 differs from __alignof for the variable in file2. This can be caused by using incompatible types when declaring variable in different files, or by using non-matching #pragma pack in different files.
To resolve this warning, either use the same type definition or use different names for the variables.
For more information, see pack and __alignof Operator.
</description>
</rule>
<rule>
<key>C4743</key>
<configkey>C4743</configkey>
<priority>CRITICAL</priority>
<name>warning C4743: 'type' has different size in 'file1' and 'file2': number and number bytes</name>
<description>
An external variable referenced or defined in two files has different types in those files, and the compiler determined that the size of the variable in file1 differs from the size of the variable in file2.
There is important case when this warning can be emitted for C++. If you declare the same types with the same name in two different files, if those declarations contain virtual functions, and if the declarations are not the same, then the compiler can emit warning C4744 for the virtual function tables. The warning occurs because there are two different sized virtual function tables for the same type, and linker must choose one of them to incorporate into the executable. It is possible that this can result in your program calling the wrong virtual function.
To resolve this warning, either use the same type definition or use different names for the types or variables.
</description>
</rule>
<rule>
<key>C4744</key>
<configkey>C4744</configkey>
<priority>CRITICAL</priority>
<name>warning C4744: 'var' has different type in 'file1' and 'file2': 'type1' and 'type2'</name>
<description>
An external variable referenced or defined in two files has different types in those files. To resolve, either make the type definitions the same, or change variable name in one of the files.
</description>
</rule>
<rule>
<key>C4746</key>
<configkey>C4746</configkey>
<priority>CRITICAL</priority>
<name>warning C4746: volatile access of '<expression>' is subject to /volatile:[iso|ms] setting; consider using __iso_volatile_load/store intrinsic functions.</name>
<description>
C4746 is emitted whenever a volatile variable is accessed directly. It is intended to help developers identify code locations that are affected by the specific volatile model currently specified (which can be controlled with the /volatile compiler option). In particular, it can be useful in locating compiler-generated hardware memory barriers when /volatile:ms is used.
The __iso_volatile_load/store intrinsics can be used to explicitly access volatile memory without being affected by the volatile model. Using these intrinsics will not trigger C4746.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4747</key>
<configkey>C4747</configkey>
<priority>CRITICAL</priority>
<name>warning C4747: Calling managed 'entrypoint': Managed code may not be run under loader lock, including the DLL entrypoint and calls reached from the DLL entrypoint</name>
<description>
The compiler found a (probable) DLL entry point compiled to MSIL. Because of potential problems with loading a DLL whose entry point has been compiled to MSIL, you are strongly discouraged from compiling a DLL entry point function to MSIL.
For more information, see Initialization of Mixed Assemblies and Linker Tools Error LNK1306.
To correct this error
- Do not compile the module with /clr.
- Mark the entry point function with #pragma unmanaged.
</description>
</rule>
<rule>
<key>C4748</key>
<configkey>C4748</configkey>
<priority>CRITICAL</priority>
<name>warning C4748: /GS can not protect parameters and local variables from local buffer overrun because optimizations are disabled in function</name>
<description>
/GS (Buffer Security Check) , which is enabled by default, cannot protect parameters and local variables from local buffer overrun in a function unless the function has optimizations enabled.
The compiler will disable optimizations if a function has inline assembly code containing flow of control (jmp or jcc, for example) statements.
Enable optimizations to resolve this warning, and to allow /GS to protect parameters and local variables from local buffer overrun
</description>
</rule>
<rule>
<key>C4756</key>
<configkey>C4756</configkey>
<priority>CRITICAL</priority>
<name>warning C4756: overflow in constant arithmetic</name>
<description>
The compiler generated an exception while doing constant arithmetic during compilation.
</description>
</rule>
<rule>
<key>C4772</key>
<configkey>C4772</configkey>
<priority>CRITICAL</priority>
<name>warning C4772: #import referenced a type from a missing type library; 'missing_type' used as a placeholder</name>
<description>
A type library was referenced with the #import directive. However, the type library contained a reference to another type library that was not referenced with #import. This other .tlb file was not found by the compiler.
Note that the compiler will not find type libraries in different directories if you use the /I (Additional Include Directories) compiler option to specify those directories. If you want the compiler to find type libraries in different directories, add those directories to the PATH environment variable.
This warning is, by default, issued as an error. C4772 can not be suppressed with /W0.
</description>
</rule>
<rule>
<key>C4788</key>
<configkey>C4788</configkey>
<priority>CRITICAL</priority>
<name>warning C4788: 'identifier' : identifier was truncated to 'number' characters</name>
<description>
The compiler limits the maximum length allowed for a function name. When the compiler generates funclets for EH/SEH code, it forms the funclet name by prepending the function name with some text, for example "__catch", "__unwind", or another string.
The resulting funclet name can be too long, and the compiler will truncate it and generate C4788.
To resolve this warning, shorten the original function name. If the function is a C++ template function or method, use a typedef for part of the name
</description>
</rule>
<rule>
<key>C4789</key>
<configkey>C4789</configkey>
<priority>CRITICAL</priority>
<name>warning C4789: destination of memory copy is too small</name>
<description>
Warns about buffer overrun when specific C run-time (CRT) functions are used, parameters are passed, and assignments are performed, such that the data sizes are known at compile time. This warning is for situations that might elude typical data-size mismatch detection.
The warning appears when data, whose length is known at compile time, is copied and put into a data block whose size is known at compile time to be too small for the data. The copy must be done by using the intrinsic form of one of the following CRT functions:
- strcpy
- memset
- memcpy, wmemcpy
The warning also appears when a parameter datatype is mismatched by using a cast, and then a copy assignment from an lvalue reference is attempted.
Visual C++ might generate this warning for a code path that does not ever execute. You can temporarily disable the warning by using #pragma, as shown in this example:
#pragma(push)
#pragma warning ( disable : 4789 )
// unused code that generates compiler warning C4789
#pragma(pop)
This keeps Visual C++ from generating the warning for that specific block of code. The #pragma(push) preserves the existing state before #pragma warning(disable: 4789) changes it. The #pragma(pop) restores the pushed state, and removes the effects of the #pragma warning(disable:4789). For more information about the C++ preprocessor directive #pragma, see warning and Pragma Directives and the __Pragma Keyword.
</description>
</rule>
<rule>
<key>C4793</key>
<configkey>C4793</configkey>
<priority>CRITICAL</priority>
<name>warning C4793: 'function' : function is compiled as native code: 'reason'</name>
<description>
The compiler cannot compile function into managed code, even though the /clr compiler option is specified. Instead, the compiler emits warning C4793 and an explanatory continuation message, and then compiles function into native code. The continuation message contains the reason text that explains why function cannot be compiled to MSIL.
This is a level 1 warning when you specify the /clr:pure compiler option.
</description>
</rule>
<rule>
<key>C4799</key>
<configkey>C4799</configkey>
<priority>CRITICAL</priority>
<name>warning C4799: No EMMS at end of function 'function'</name>
<description>
The function has at least one MMX instruction, but does not have an EMMS instruction. When a multimedia instruction is used, an EMMS instruction should also be used to clear the multimedia tag word at the end of the MMX code. For more information on EMMS instructions, see Guidelines for When to Use EMMS.
You may get C4799 when using ivec.h, indicating that the code does not use properly execute the EMMS instruction before returning. This is a false warning for these headers. You may turn these off by defining _SILENCE_IVEC_C4799 in ivec.h. However, be aware that this will also keep the compiler from giving correct warnings of this type.
For related information, see the Intel's MMX Instruction Set.
</description>
</rule>
<rule>
<key>C4800</key>
<configkey>C4800</configkey>
<priority>CRITICAL</priority>
<name>warning C4800: 'type' : forcing value to bool 'true' or 'false' (performance warning)</name>
<description>
This warning is generated when a value that is not bool is assigned or coerced into type bool. Typically, this message is caused by assigning int variables to bool variables where the int variable contains only values true and false, and could be redeclared as type bool. If you cannot rewrite the expression to use type bool, then you can add "!=0" to the expression, which gives the expression type bool. Casting the expression to type bool will not disable the warning, which is by design.
</description>
</rule>
<rule>
<key>C4801</key>
<configkey>C4801</configkey>
<priority>CRITICAL</priority>
<name>warning C4801: Return by reference is not verifiable: reason</name>
<description>
You cannot store a tracking reference into a local variable and then return it verifiably.
A reference can only be verifiably returned when it can be tracked by the verifier from creation to return point and when it is a reference to an element of an array, or a member of a class.
For more information, see Peverify.exe (PEVerify Tool).
A reference must remain on the stack from creation to return in order to be verifiable.
C4801 is always issued as an error. You can turn off this warning with the #pragma warning or /wd; see warning or /w, /Wn, /WX, /Wall, /wln, /wdn, /wen, /won (Warning Level) for more information.
</description>
</rule>
<rule>
<key>C4803</key>
<configkey>C4803</configkey>
<priority>CRITICAL</priority>
<name>warning C4803: 'method' : the raise method has a different storage class from that of the event, 'event'</name>
<description>
Event methods must have the same storage class as the event declaration. The compiler adjusts the event's methods so that the storage classes are the same.
This warning can occur if you have a class that implements an event from an interface. The compiler does not implicitly generate a raise method for an event in an interface. When you implement that interface in a class, the compiler does implicitly generate a raise method and that method will not be virtual, hence the warning.
See warning pragma for information on how to turn a warning off.
</description>
</rule>
<rule>
<key>C4804</key>
<configkey>C4804</configkey>
<priority>CRITICAL</priority>
<name>warning C4804: 'operation' : unsafe use of type 'bool' in operation</name>
<description>
This warning is generated for comparison operations between bool and int.
</description>
</rule>
<rule>
<key>C4805</key>
<configkey>C4805</configkey>
<priority>CRITICAL</priority>
<name>warning C4805: 'operation' : unsafe mix of type 'type' and type 'type' in operation</name>
<description>
This warning is for when you used a bool variable or value in an unexpected way. For example, C4804 is generated if you use operators such as the negative unary operator (-) or the complement operator (~). The compiler evaluates the expression.
</description>
</rule>
<rule>
<key>C4815</key>
<configkey>C4815</configkey>
<priority>CRITICAL</priority>
<name>warning C4815: 'var' : zero-sized array in stack object will have no elements (unless the object is an aggregate that has been aggregate initialized)</name>
<description>
An array with an undefined number of elements (zero-sized array) is the last member of a type and an object of the type was created on the stack. No memory will be allocated for the array. If you need a useful constructor, you can allocate memory for the struct on the heap.
</description>
</rule>
<rule>
<key>C4819</key>
<configkey>C4819</configkey>
<priority>CRITICAL</priority>
<name>warning C4819: The file contains a character that cannot be represented in the current code page (number). Save the file in Unicode format to prevent data loss.</name>
<description>
C4819 occurs when an ANSI source file is compiled on a system with a codepage that cannot represent all characters in the file.
To resolve C4819, save the file in Unicode format.
</description>
</rule>
<rule>
<key>C4820</key>
<configkey>C4820</configkey>
<priority>CRITICAL</priority>
<name>warning C4820: 'bytes' bytes padding added after construct 'member_name'</name>
<description>
The type and order of elements caused the compiler to add padding to the end of a struct. See align for more information on padding in a struct.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4821</key>
<configkey>C4821</configkey>
<priority>CRITICAL</priority>
<name>warning C4821: Unable to determine Unicode encoding type, please save the file with signature (BOM)</name>
<description>
The compiler could not determine the encoding type for a file. To resolve this warning, save the file with a byte order marker. See Managing Files with Encoding for more information.
</description>
</rule>
<rule>
<key>C4823</key>
<configkey>C4823</configkey>
<priority>CRITICAL</priority>
<name>warning C4823: 'function' : uses pinning pointers but unwind semantics are not enabled. Consider using /EHa</name>
<description>
To unpin an object on the managed heap pointed to by a pinning pointer declared in a block scope, the compiler simulates the behavior of destructors of local classes, "pretending" the pinning pointer has a destructor that nullifies the pointer. To enable a call to a destructor after throwing an exception, you must enable object unwinding, which you can do by using /EHsc.
You can also manually unpin the object and ignore the warning.
</description>
</rule>
<rule>
<key>C4826</key>
<configkey>C4826</configkey>
<priority>CRITICAL</priority>
<name>warning C4826: Conversion from 'type1 ' to 'type_2' is sign-extended. This may cause unexpected runtime behavior.</name>
<description>
This warning indicates that the compiler performed sign extension when a 32-bit pointer was cast to a 64-bit variable.
If the extension was performed on a windows HANDLE type, it is safe to ignore this warning. If the extension was performed on a pointer type, you should modify the cast to prevent the sign extension (see example below).
C4826 is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4829</key>
<configkey>C4829</configkey>
<priority>CRITICAL</priority>
<name>warning C4829: Possibly incorrect parameters to function main. Consider 'int main(array<System::String^>^ argv)'</name>
<description>
Certain functions, such as main, cannot take reference type parameters. While compilation will succeed, the resulting image will probably not run
</description>
</rule>
<rule>
<key>C4832</key>
<configkey>C4832</configkey>
<priority>CRITICAL</priority>
<name>warning C4832: token 'token' is illegal after UDT 'type name'</name>
<description>
A member of a UDT (user-defined type, such a class or struct) was qualified incorrectly. The compiler issues this warning and proceeds as if the qualification was specified correctly.
</description>
</rule>
<rule>
<key>C4835</key>
<configkey>C4835</configkey>
<priority>CRITICAL</priority>
<name>warning C4835: 'variable' : the initializer for exported data will not be run until managed code is first executed in the host assembly</name>
<description>
When accessing data between managed components, it is recommended that you not use native C++ import and export mechanisms. Instead, declare your data members inside a managed type and reference the metadata with #using in the client. For more information, see #using Directive (C++).
</description>
</rule>
<rule>
<key>C4836</key>
<configkey>C4836</configkey>
<priority>CRITICAL</priority>
<name>warning C4836: nonstandard extension used : 'type' : local types or unnamed types cannot be used as template arguments</name>
<description>
The C++ standard does not allow the use of local types as template arguments, but the Visual C++ compiler does allow this under /Ze. C4836 is an informational warning, to let you know that you are writing non-conformant code. For more information, see /Za, /Ze (Disable Language Extensions).
C4836 is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4837</key>
<configkey>C4837</configkey>
<priority>CRITICAL</priority>
<name>warning C4837: trigraph detected: '??%c' replaced by '%c'</name>
<description>
The detected trigraph is replaced by the indicated character.
The compiler translates trigraphs before any other processing is completed. Use the character escape sequence, \?, to prevent the misinterpretation of a character sequence that resembles a trigraph. For more information about trigraphs, see Trigraphs. For more information about escape sequences, see Escape Sequences.
C4837 is off by default. See Compiler Warnings That Are Off by Default for more information.
To correct this error
- use the character escape sequence, \?, instead of one of the '?' characters in the source code.
</description>
</rule>
<rule>
<key>C4867</key>
<configkey>C4867</configkey>
<priority>CRITICAL</priority>
<name>warning C4867: 'function': function call missing argument list; use 'call' to create a pointer to member</name>
<description>
A pointer to member function was initialized incorrectly.
This warning can be generated as a result of compiler conformance work that was done for Visual C++ 2005: enhanced pointer-to-member conformance. Code that compiled prior to Visual C++ 2005 will now generate C4867.
This warning is always issued as an error. Use the warning pragma to disable this warning. For more information about C4867 and MFC/ATL, see _ATL_ENABLE_PTM_WARNING.
</description>
</rule>
<rule>
<key>C4905</key>
<configkey>C4905</configkey>
<priority>CRITICAL</priority>
<name>warning C4905: wide string literal cast to 'LPSTR'</name>
<description>
The compiler detected an unsafe cast. The cast did succeed, but you should use a conversion routine.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4906</key>
<configkey>C4906</configkey>
<priority>CRITICAL</priority>
<name>warning C4906: string literal cast to 'LPWSTR'</name>
<description>
The compiler detected an unsafe cast. The cast did succeed, but you should use a conversion routine.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4917</key>
<configkey>C4917</configkey>
<priority>CRITICAL</priority>
<name>warning C4917: 'declarator' : a GUID can only be associated with a class, interface or namespace</name>
<description>
A user-defined structure other than class, interface, or namespace cannot have a GUID.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4927</key>
<configkey>C4927</configkey>
<priority>CRITICAL</priority>
<name>warning C4927: illegal conversion; more than one user-defined conversion has been implicitly applied</name>
<description>
More than one user-defined conversion is implicitly applied to a single value - the compiler did not find an explicit conversion but did find a conversion, which it used.
</description>
</rule>
<rule>
<key>C4928</key>
<configkey>C4928</configkey>
<priority>CRITICAL</priority>
<name>warning C4928: illegal copy-initialization; more than one user-defined conversion has been implicitly applied</name>
<description>
More than one user-defined conversion routine was found. The compiler executed the code in all such routines.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4929</key>
<configkey>C4929</configkey>
<priority>CRITICAL</priority>
<name>warning C4929: 'file': typelibrary contains a union; ignoring the 'embedded_idl' qualifier</name>
<description>
The embedded_idl attribute of #import could not be applied to the type library because a union is present in the type library. To resolve this warning, don't use embedded_idl.
</description>
</rule>
<rule>
<key>C4930</key>
<configkey>C4930</configkey>
<priority>CRITICAL</priority>
<name>warning C4930: 'prototype': prototyped function not called (was a variable definition intended?)</name>
<description>
The compiler detected an unused function prototype. If the prototype was intended as a variable declaration, remove the open/close parentheses.
</description>
</rule>
<rule>
<key>C4931</key>
<configkey>C4931</configkey>
<priority>CRITICAL</priority>
<name>warning C4931: we are assuming the type library was built for number-bit pointers</name>
<description>
Explicit information was not supplied with the ptrsize attribute of the #import directive; the compiler concluded that pointer size of the type library is number.
This warning is off by default. See Compiler Warnings That Are Off by Default for more information.
</description>
</rule>
<rule>
<key>C4945</key>
<configkey>C4945</configkey>
<priority>CRITICAL</priority>
<name>warning C4945: 'symbol' : cannot import symbol from 'assembly2': as 'symbol' has already been imported from another assembly 'assembly1'</name>
<description>
A symbol was imported from a referenced assembly but that symbol was already imported from another referenced assembly. Either do not reference one of the assemblies or get the symbol name changed in one of the assemblies.
</description>
</rule>
<rule>
<key>C4946</key>
<configkey>C4946</configkey>
<priority>CRITICAL</priority>
<name>warning C4946: reinterpret_cast used between related classes: 'class1' and 'class2'</name>
<description>
Do not use reinterpret_cast to cast between related types. Use static_cast instead, or for polymorphic types, use dynamic_cast.
By default, this warning is off. For more information, see Compiler Warnings That Are Off by Default.
</description>
</rule>
<rule>
<key>C4948</key>
<configkey>C4948</configkey>
<priority>CRITICAL</priority>
<name>warning C4948: return type of 'accessor' does not match the last parameter type of the corresponding setter</name>
<description>
The compiler found a mismatch between what data type is being get and set for an indexed property.
C4948 is only reachable using /clr:oldSyntax.
</description>
</rule>
<rule>
<key>C4949</key>
<configkey>C4949</configkey>
<priority>CRITICAL</priority>
<name>warning C4949: pragmas 'managed' and 'unmanaged' are meaningful only when compiled with '/clr[:option]'</name>
<description>
The compiler ignores the managed and unmanaged pragmas if the source code is not compiled with /clr. This warning is informational.
</description>
</rule>
<rule>
<key>C4964</key>
<configkey>C4964</configkey>
<priority>CRITICAL</priority>
<name>warning C4964: No optimization options were specified; profile info will not be collected</name>
<description>
/GL and /LTCG were specified, but no optimizations were requested, so no .pgc files will be generated and, therefore, no profile-guided optimizations will be possible.
If you want .pgc files to be generated when you run your application, specify one of the /O compiler options.
</description>
</rule>
<rule>
<key>C4965</key>
<configkey>C4965</configkey>
<priority>CRITICAL</priority>
<name>warning C4965: implicit box of integer 0; use nullptr or explicit cast</name>
<description>
Visual C++ features implicit boxing of value types. An instruction that resulted in a null assignment using Managed Extensions for C++ now becomes an assignment to a boxed int.
For more information, see Boxing (Visual C++).
</description>
</rule>
<rule>
<key>C4980</key>
<configkey>C4980</configkey>
<priority>CRITICAL</priority>
<name>warning C4980: 'keyword' : use of this keyword requires /clr:oldSyntax command line option</name>
<description>
A keyword from a previous version was used. Update your code to use newer syntax, or use /clr:oldSyntax. For more information about the newer syntax, see Component Extensions for Runtime Platforms.
C4980 is a warning that is always issued as an error. Use /wd to turn the warning off. See /w, /Wn, /WX, /Wall, /wln, /wdn, /wen, /won (Warning Level) for more information.
</description>
</rule>
<rule>
<key>C4986</key>
<configkey>C4986</configkey>
<priority>CRITICAL</priority>
<name>warning C4986: 'function': exception specification does not match previous declaration</name>
<description>
This warning can be generated when there is an exception specification in one declaration and not the other.
By default, C4986 is off. For more information, see Compiler Warnings That Are Off by Default.
</description>
</rule>
<rule>
<key>C4995</key>
<configkey>C4995</configkey>
<priority>CRITICAL</priority>
<name>warning C4995: 'function': name was marked as #pragma deprecated</name>
<description>
The compiler encountered a function that was marked with pragma deprecated. The function may no longer be supported in a future release. You can turn this warning off with the warning pragma (example below).
</description>
</rule>
<rule>
<key>C4996</key>
<configkey>C4996</configkey>
<priority>CRITICAL</priority>
<name>warning C4996: 'function': was declared deprecated</name>
<description>
The compiler encountered a function that was marked with deprecated. The function may no longer be supported in a future release. You can turn this warning off with the warning pragma (example below).
C4996 is generated for the line on which the function is declared and for the line on which the function is used.
You will see C4996 if you are using members of the <hash_map>; and <hash_set>; header files in the std namespace. See The stdext Namespace for more information.
Some CRT and Standard C++ Library functions have been deprecated in favor of new, more secure functions. For more information about deprecated functions, see Security Features in the CRT and Safe Libraries: Standard C++ Library.
C4996 can also occur if you use MFC or ATL functions that were deprecated for security reasons. To suppress these warnings, see _AFX_SECURE_NO_WARNINGS and _ATL_SECURE_NO_WARNINGS.
C4996 can also occur when you use the marshaling library. In this case C4996 is an error, not a warning. This error will occur when you use marshal_as to convert between two data types that require a marshal_context Class. You will also receive this error when the marshaling library does not support a conversion. For more information about the marshaling library, see Overview of Marshaling in C++.
</description>
</rule>
<!-- analysis -->
<rule>
<key>C6001</key>
<configkey>C6001</configkey>
<priority>CRITICAL</priority>
<name>warning C6001: using uninitialized memory <variable></name>
<description>
This warning is reported when an uninitialized local variable is used before it is assigned a value. This could lead to unpredictable results. You should always initialize variables before use.
</description>
</rule>
<rule>
<key>C6011</key>
<configkey>C6011</configkey>
<priority>CRITICAL</priority>
<name>warning C6011: dereferencing NULL pointer <name></name>
<description>
This warning indicates that a null pointer is being dereferenced. If the pointer value is invalid, the result is undefined.
</description>
</rule>
<rule>
<key>C6014</key>
<configkey>C6014</configkey>
<priority>BLOCKER</priority>
<name>warning C6014: Leaking memory.</name>
<description>
This warning indicates that the specified pointer points to allocated memory or some other allocated resource that has not been freed. The analyzer checks for this condition only when the _Analysis_mode_(_Analysis_local_leak_checks_) SAL annotation is specified. By default, this annotation is specified for Windows kernel mode (driver) code. For more information about SAL annotations, see Using SAL Annotations to Reduce C/C++ Code Defects.
</description>
</rule>
<rule>
<key>C6029</key>
<configkey>C6029</configkey>
<name>warning C6029: possible buffer overrun in call to <function>: use of unchecked value</name>
<description>
This warning indicates that a function that takes a buffer and a size is being passed a unchecked size. The data read-in from some external source has not been verified to see whether it is smaller than the buffer size. An attacker might intentionally specify a much larger than expected value for the size, which will lead to a buffer overrun.
Generally, whenever you read data from an untrusted external source, make sure to verify it for validity. It is usually appropriate to verify the size to make sure it is in the expected range.
</description>
</rule>
<rule>
<key>C6031</key>
<configkey>C6031</configkey>
<priority>CRITICAL</priority>
<name>warning C6031: return value ignored: <function> could return unexpected value</name>
<description>
This warning indicates that the calling function is not checking the return value of a function call that signals failure via its return value. Depending on which function is being called, this defect can lead to seemingly random program misbehavior, including crashes and data corruptions in error conditions or low-resource situations.
In general, it is not safe to assume that a call to function requiring disk, network, memory, or other resources will always succeed. The caller should always check the return value and handle error cases appropriately. Also consider using the _Must_inspect_result_ annotation, which checks that the value is examined in a useful way.
</description>
</rule>
<rule>
<key>C6053</key>
<configkey>C6053</configkey>
<priority>CRITICAL</priority>
<name>warning C6053: call to <function> may not zero-terminate string <variable></name>
<description>
This warning indicates that the specified function has been called in such a way that the resulting string might not be zero-terminated. This defect might cause an exploitable buffer overrun or crash. This warning is also generated if an annotated function expects a null terminated string is passed a string that is not null terminated.
Most C standard library and Win32 string handling functions require and produce zero-terminated strings. A few 'counted string' functions (including strncpy, wcsncpy, _mbsncpy, _snprintf, and snwprintf) do not produce zero-terminated strings if they exactly fill their buffer. In this case, a subsequent call to a string function that expects a zero-terminated string will go beyond the end of the buffer looking for the zero. The program should make sure that the string ends with a zero. In general, you should pass a length to the 'counted string' function one smaller than the size of the buffer and then explicitly assign zero to the last character in the buffer.
</description>
</rule>
<rule>
<key>C6054</key>
<configkey>C6054</configkey>
<priority>CRITICAL</priority>
<name>warning C6054: string <variable> may not be zero-terminated</name>
<description>
This warning indicates that a function that requires zero-terminated string was passed a non-zero terminated string. A function that expects a zero-terminated string will go beyond the end of the buffer to look for the zero. This defect might cause an exploitable buffer overrun error or crash. The program should make sure that the string ends with a zero.
</description>
</rule>
<rule>
<key>C6057</key>
<configkey>C6057</configkey>
<priority>CRITICAL</priority>
<name>warning C6057: buffer overrun due to number of characters/number of bytes mismatch in call to <function></name>
<description>
This warning indicates that a function that expects the number of characters is being passed the number of bytes instead. With wide (Unicode) characters, the values are different. This defect might cause an exploitable buffer overrun or crash.
A common cause of this defect is using sizeof on a character array. The sizeof operator always computes the number of bytes; for ANSI characters this is the same as the number of characters, but for Unicode characters it is twice the number of characters.
It is usually safe to compute the number of elements in an array by dividing the size of the array by the size of each element.
</description>
</rule>
<rule>
<key>C6059</key>
<configkey>C6059</configkey>
<priority>CRITICAL</priority>
<name>warning C6059: Incorrect length parameter in call to <function>. Pass the number of remaining characters, not the buffer size of <variable></name>
<description>
This warning indicates that a call to a string concatenation function is probably passing an incorrect value for the number of characters to concatenate. This defect might cause an exploitable buffer overrun or crash. A common cause of this defect is passing the buffer size, instead of the remaining number of characters in the buffer, to the string manipulation function.
</description>
</rule>
<rule>
<key>C6063</key>
<configkey>C6063</configkey>
<priority>CRITICAL</priority>
<name>warning C6063: missing string argument to <function> corresponding to conversion specifier <number></name>
<description>
This warning indicates that not enough arguments are being provided to match a format string; at least one of the missing arguments is a string. This defect can cause crashes and buffer overflows (if the called function is of the sprintf family), as well as potentially incorrect output.
</description>
</rule>
<rule>
<key>C6064</key>
<configkey>C6064</configkey>
<priority>CRITICAL</priority>
<name>warning C6064: missing integer argument to <function> corresponding to conversion specifier <number></name>
<description>
This warning indicates that not enough arguments are being provided to match a format string and one of the missing arguments is an integer. This defect can cause incorrect output.
</description>
</rule>
<rule>
<key>C6066</key>
<configkey>C6066</configkey>
<priority>CRITICAL</priority>
<name>warning C6066: non-pointer passed as parameter <number> when pointer is required in call to <function></name>
<description>
This warning indicates that the format string specifies that a pointer is required, for example, a %n or %p specification for printf or a %d for scanf, but a non-pointer is being passed. This defect is likely to cause a crash or corruption of some form.
</description>
</rule>
<rule>
<key>C6067</key>
<configkey>C6067</configkey>
<priority>CRITICAL</priority>
<name>warning C6067: parameter <number> in call to <function> must be the address of the string</name>
<description>
This warning indicates a mismatch between the format specifier and the function parameter. Even though the warning suggests using the address of the string, you must check the type of parameter a function expects before correcting the problem. For example, a %s specification for printf requires a string argument, but a %s specification in scanf requires an address of the string.
This defect is likely to cause a crash or corruption of some form
</description>
</rule>
<rule>
<key>C6101</key>
<configkey>C6101</configkey>
<priority>CRITICAL</priority>
<name>warning C6101: Returning uninitialized memory</name>
<description>
A successful path through the function does not set the named _Out_ parameter. This message is generated based on SAL annotations that indicate that the function in question always succeeds. A function that doesn’t return a success/failure indication should set all of its _Out_ parameters because the analyzer assumes that the _Out_ parameter is uninitialized data before the function is called, and that the function will set the parameter so that it’s no longer uninitialized. If the function does indicate success/failure, then the _Out_ parameter doesn't have to be set in the case of failure, and you can detect and avoid the uninitialized location. In either case, the objective is to avoid the reading of an uninitialized location. If the function sometimes doesn’t touch an _Out_ parameter that’s subsequently used, then the parameter should be initialized before the function call and be marked with the _Inout_ annotation, or the more explicit _Pre_null_ or _Pre_satisfies_() when appropriate. "Partial success" can be handled with the _When_ annotation. For more information, see Using SAL Annotations to Reduce C/C++ Code Defects.
</description>
</rule>
<rule>
<key>C6200</key>
<configkey>C6200</configkey>
<priority>CRITICAL</priority>
<name>warning C6200: index <name> is out of valid index range <min> to <max> for non-stack buffer <variable> </name>
<description>
This warning indicates that an integer offset into the specified array exceeds the maximum bounds of that array. This defect might cause random behavior or crashes.
One common cause of this defect is using the size of an array as an index into the array. Because C/C++ array indexing is zero-based, the maximum legal index into an array is one less than the number of array elements.
</description>
</rule>
<rule>
<key>C6201</key>
<configkey>C6201</configkey>
<priority>CRITICAL</priority>
<name>warning C6201: buffer overrun for <variable>, which is possibly stack allocated: index <name> is out of valid index range <min> to <max></name>
<description>
This warning indicates that an integer offset into the specified stack array exceeds the maximum bounds of that array. This defect might cause random behavior or crashes.
One common cause of this defect is using an array’s size as an index into the array. Because C/C++ array indexing is zero-based, the maximum legal index into an array is one less than the number of array elements.
</description>
</rule>
<rule>
<key>C6202</key>
<configkey>C6202</configkey>
<priority>CRITICAL</priority>
<name>warning C6202: buffer overrun for <variable>, which is possibly stack allocated, in call to <function>: length <size> exceeds buffer size <max></name>
<description>
This warning indicates that a parameter pointing to a stack buffer of known size is being passed into a function that copies more bytes into it than that size. This situation will cause a buffer overrun. This defect is likely to cause an exploitable security hole or a program crash.
</description>
</rule>
<rule>
<key>C6203</key>
<configkey>C6203</configkey>
<priority>CRITICAL</priority>
<name>warning C6203: buffer overrun for buffer <variable> in call to <function>: length <size> exceeds buffer size </name>
<description>
This warning indicates that a parameter that points to a non-stack buffer of known size is being passed into a function that copies more bytes into it than that size. This situation will cause a buffer overrun.
This defect might cause an exploitable security hole or a program crash.
</description>
</rule>
<rule>
<key>C6204</key>
<configkey>C6204</configkey>
<priority>CRITICAL</priority>
<name>warning C6204: possible buffer overrun in call to <function>: use of unchecked parameter <variable></name>
<description>
This warning indicates that a function call is being made that could potentially lead to an overrun of a stack buffer, depending on the possible values of parameters to the function being analyzed. This defect might cause an exploitable buffer overrun or crash.
It is a good idea to review the code, as well as the callers to this function, to see whether the function can ever be called with unexpected data. If it is not clear that all calls are safe, it might be appropriate to validate the input to the function by checking the length of any input strings or by annotating the function parameter using appropriate properties.
</description>
</rule>
<rule>
<key>C6209</key>
<configkey>C6209</configkey>
<priority>CRITICAL</priority>
<name>warning C6209: using 'sizeof<variable1>' as parameter <number> in call to <function> where <variable2> may be an array of wide characters</name>
<description>
warning C6209: using 'sizeof<variable1>' as parameter <number> in call to <function> where <variable2> may be an array of wide characters, did you intend to use character count rather than byte count?
This warning indicates that a parameter to a function call might incorrectly be a byte count instead of a character count. If this is the case, this defect is likely to cause a memory corruption or program crash, although some cases might cause an exploitable security hole.
A common cause of this defect is using sizeof on a character array. The sizeof operator always computes the number of bytes. For ANSI characters this is the same as the number of characters; however, for Unicode characters it is twice the number of characters.
It is usually safe to compute the number of elements in an array by dividing the size of the array by the size of each element.
This warning is generated when:
- A variable is passed as one parameter and sizeof that variable is passed as another parameter.
- Both the variable type and the formal parameter type are some variety of pointer-to-wide char.
</description>
</rule>
<rule>
<key>C6211</key>
<configkey>C6211</configkey>
<priority>CRITICAL</priority>
<name>warning C6211: Leaking memory <pointer> due to an exception. Consider using a local catch block to clean up memory</name>
<description>
This warning indicates that allocated memory is not being freed when an exception is thrown. The statement at the end of the path could throw an exception. The analyzer checks for this condition only when the _Analysis_mode_(_Analysis_local_leak_checks_) SAL annotation is specified. By default, this annotation is specified for Windows kernel mode (driver) code. For more information about SAL annotations, see Using SAL Annotations to Reduce C/C++ Code Defects.
</description>
</rule>
<rule>
<key>C6214</key>
<configkey>C6214</configkey>
<priority>CRITICAL</priority>
<name>warning C6214: cast between semantically different integer types: HRESULT to a Boolean type</name>
<description>
This warning indicates that an HRESULT is being cast to a Boolean type. The success value (S_OK) of an HRESULT equals 0. However, 0 indicates failure for a Boolean type. Casting an HRESULT to a Boolean type and then using it in a test expression will yield an incorrect result. Sometimes, this warning occurs if an HRESULT is being stored in a Boolean variable. Any comparison that uses the Boolean variable to test for HRESULT success or failure could lead to incorrect results.
</description>
</rule>
<rule>
<key>C6215</key>
<configkey>C6215</configkey>
<priority>CRITICAL</priority>
<name>warning C6215: cast between semantically different integer types: a Boolean type to HRESULT </name>
<description>
This warning indicates that a Boolean is being cast to an HRESULT. Boolean types indicate success by a non-zero value, whereas success (S_OK) in HRESULT is indicated by a value of 0. Casting a Boolean type to an HRESULT and then using it in a test expression will yield an incorrect result.
This warning frequently occurs when a Boolean is used as an argument to SUCCEEDED or FAILED macro, which explicitly casts their arguments to an HRESULT.
</description>
</rule>
<rule>
<key>C6216</key>
<configkey>C6216</configkey>
<priority>CRITICAL</priority>
<name>warning C6216: compiler-inserted cast between semantically different integral types: a Boolean type to HRESULT</name>
<description>
This warning indicates that a Boolean is being used as an HRESULT without being explicitly cast. Boolean types indicate success by a non-zero value; success (S_OK) in HRESULT is indicated by a value of 0. The typical failure value for functions that return a Boolean false is a success status when it is tested as an HRESULT. This is likely to lead to incorrect results.
</description>
</rule>
<rule>
<key>C6217</key>
<configkey>C6217</configkey>
<priority>CRITICAL</priority>
<name>warning C6217: Implicit cast between semantically different integer types: testing HRESULT with 'not'. Consider using SUCCEEDED or FAILED macro instead.</name>
<description>
This warning indicates that an HRESULT is being tested with the not (!) operator. A success (S_OK) in HRESULT is indicated by a value of 0. However, 0 indicates failure for a Boolean type. Testing HRESULT with the not operator (!) to determine which code block to run can cause following the wrong code path. This will lead to unwanted results.
</description>
</rule>
<rule>
<key>C6219</key>
<configkey>C6219</configkey>
<priority>CRITICAL</priority>
<name>warning C6219: Implicit cast between semantically different integer types: comparing HRESULT to 1 or TRUE. Consider using SUCCEEDED or FAILED macro instead</name>
<description>
This warning indicates that an HRESULT is being compared with an explicit, non-HRESULT value of one (1). This is likely to lead to incorrect results because the typical success value of HRESULT (S_OK) is 0; comparing it to a Boolean type will implicitly convert it to false.
</description>
</rule>
<rule>
<key>C6220</key>
<configkey>C6220</configkey>
<priority>CRITICAL</priority>
<name>warning C6220 - Implicit cast between semantically different integer types: comparing HRESULT to -1. Consider using SUCCEEDED or FAILED macro instead</name>
<description>
This warning indicates that an HRESULT is being compared with an explicit, non-HRESULT value of -1, which is not a well-formed HRESULT. A failure in HRESULT (E_FAIL) is not represented by a -1. Therefore, an implicit cast of an HRESULT to an integer will generate an incorrect value and is likely to lead to the wrong result.
</description>
</rule>
<rule>
<key>C6221</key>
<configkey>C6221</configkey>
<priority>CRITICAL</priority>
<name>warning C6221: Implicit cast between semantically different integer types: comparing HRESULT to an integer. Consider using SUCCEEDED or FAILED macros instead</name>
<description>
This warning indicates that an HRESULT is being compared to an integer other than zero. A success in HRESULT (S_OK) is represented by a 0. Therefore, an implicit cast of an HRESULT to an integer will generate an incorrect value and is likely to lead to the wrong result. It is often caused by mistakenly expecting a function to return an integer when it actually returns an HRESULT.
</description>
</rule>
<rule>
<key>C6225</key>
<configkey>C6225</configkey>
<priority>CRITICAL</priority>
<name>warning C6225: Implicit cast between semantically different integer types: assigning 1 or TRUE to HRESULT. Consider using S_FALSE instead</name>
<description>
This warning indicates that an HRESULT is being assigned or initialized with a value of an explicit 1. Boolean types indicate success by a non-zero value; success (S_OK) in HRESULT is indicated by a value of 0. This warning is frequently caused by accidental confusion of Boolean and HRESULT types. To indicate success, the symbolic constant S_OK should be used.
</description>
</rule>
<rule>
<key>C6226</key>
<configkey>C6226</configkey>
<priority>CRITICAL</priority>
<name>warning C6226: Implicit cast between semantically different integer types: assigning -1 to HRESULT. Consider using E_FAIL instead.</name>
<description>
This warning indicates that an HRESULT is being assigned or initialized with a value of an explicit -1. This warning is frequently caused by accidental confusion of integer and HRESULT types. To indicate success, the symbolic constant S_OK should be used. To indicate failure, the symbolic constants starting with E_constant should be used.
</description>
</rule>
<rule>
<key>C6230</key>
<configkey>C6230</configkey>
<priority>CRITICAL</priority>
<name>warning C6230: implicit cast between semantically different integer types: using HRESULT in a Boolean context </name>
<description>
This warning indicates that a bare HRESULT is being used in a context, such as if statement, where a Boolean result is expected. This is likely to yield incorrect results. For example, the typical success value for HRESULT (S_OK) is false when it is tested as a Boolean.
</description>
</rule>
<rule>
<key>C6235</key>
<configkey>C6235</configkey>
<priority>CRITICAL</priority>
<name>warning C6235: (<non-zero constant> || <expression>) is always a non-zero constant</name>
<description>
This warning indicates that a non-zero constant value, other than one, was detected on the left side of a logical-or operation that occurs in a test context. The right side of the logical-or operation is not evaluated because the resulting expression always evaluates to true. This is referred to as "short-circuit evaluation."
A non-zero constant value, other than one, suggests that the bitwise-AND operator (&) may have been intended. This warning is not generated for the common idiom when the non-zero constant is 1, because of its use for selectively enabling code paths, but it is generated if the non-zero constant evaluates to 1, for example 1+0.
</description>
</rule>
<rule>
<key>C6236</key>
<configkey>C6236</configkey>
<priority>CRITICAL</priority>
<name>warning C6236: (<expression> || <non-zero constant>) is always a non-zero constant</name>
<description>
This warning indicates that a non-zero constant value, other than one, was detected on the right side of a logical-or operation that occurs in a test context. The left side of the logical-or operation is not evaluated because the resulting expression always evaluates to true. This is referred to as "short-circuit evaluation."
A constant value other than one suggests that the bitwise-AND operator (&) may have been intended. This warning is not generated for the common idiom when the non-zero constant is 1, because of its use for selectively enabling code paths, but it is generated if the non-zero constant evaluates to 1, for example 1+0.
</description>
</rule>
<rule>
<key>C6237</key>
<configkey>C6237</configkey>
<priority>CRITICAL</priority>
<name>warning C6237: (<zero> && <expression>) is always zero. <expression> is never evaluated and may have side effects</name>
<description>
This warning indicates that a constant value of zero was detected on the left side of a logical-and operation that occurs in a test context. The resulting expression always evaluates to false. Therefore, the right side of the logical-AND operation is not evaluated. This is referred to as "short-circuit evaluation."
You should examine the right side of the expression carefully to ensure that any side effects such as assignment, function call, increment, and decrement operations needed for proper functionality are not affected by the short-circuit evaluation.
The expression (0 && n) produces no side effects and is commonly used to selectively choose code paths.
</description>
</rule>
<rule>
<key>C6239</key>
<configkey>C6239</configkey>
<priority>CRITICAL</priority>
<name>warning C6239: (<non-zero constant> && <expression>) always evaluates to the result of <expression>. Did you intend to use the bitwise-and operator?</name>
<description>
This warning indicates that a non-zero constant value, other than one, was detected on the left side of a logical-AND operation that occurs in a test context. For example, the expression ( 2 && n ) is reduced to (!!n), which is the Boolean value of n.
This warning typically indicates an attempt to check a bit mask in which the bitwise-AND (&) operator should be used, and is not generated if the non-zero constant evaluates to 1 because of its use for selectively choosing code paths.
</description>
</rule>
<rule>
<key>C6240</key>
<configkey>C6240</configkey>
<priority>CRITICAL</priority>
<name>warning C6240: (<expression> && <non-zero constant>) always evaluates to the result of <expression>. Did you intend to use the bitwise-and operator?</name>
<description>
This warning indicates that a non-zero constant value, other than one, was detected on the right side of a logical-and operation that occurs in a test context. For example, the expression (n && 3) reduces to (!!n), which is the Boolean value of n.
This warning typically indicates an attempt to check a bit mask in which the bitwise-AND (&) operator should be used. It is not generated if the non-zero constant evaluates to 1 because of its use for selectively choosing code paths.
</description>
</rule>
<rule>
<key>C6242</key>
<configkey>C6242</configkey>
<priority>CRITICAL</priority>
<name>warning C6242: A jump out of this try-block forces local unwind. Incurs severe performance penalty</name>
<description>
This warning indicates that a jump statement causes control-flow to leave the protected block of a try-finally other than by fall-through.
Leaving the protected block of a try-finally other than by falling through from the last statement requires local unwind to occur. Local unwind typically requires approximately 1000 machine instructions; therefore, it is detrimental to performance.
Use _leave to exit the protected block of a try-finally
</description>
</rule>
<rule>
<key>C6244</key>
<configkey>C6244</configkey>
<priority>CRITICAL</priority>
<name>warning C6244: local declaration of <variable> hides previous declaration at <line> of <file></name>
<description>
This warning indicates that a declaration has the same name as a declaration at an outer scope and hides the previous declaration. You will not be able to refer to the previous declaration from inside the local scope. Any intended use of the previous declaration will end up using the local declaration This warning only identifies a scope overlap and not lifetime overlap.
</description>
</rule>
<rule>
<key>C6246</key>
<configkey>C6246</configkey>
<priority>CRITICAL</priority>
<name>warning C6246: Local declaration of <variable> hides declaration of same name in outer scope. Additional Information: See previous declaration at <location>.</name>
<description>
This warning indicates that two declarations have the same name at local scope. The name at outer scope is hidden by the declaration at the inner scope. Any intended use of the outer scope declaration will result in the use of local declaration.
</description>
</rule>
<rule>
<key>C6248</key>
<configkey>C6248</configkey>
<priority>CRITICAL</priority>
<name>warning C6248: setting a SECURITY_DESCRIPTOR’s DACL to NULL will result in an unprotected object</name>
<description>
This warning identifies a call that sets a SECURITY_DESCRIPTOR's DACL field to null. If the DACL that belongs to the security descriptor of an object is set to NULL, a null DACL is created. A null DACL grants full access to any user who requests it; normal security checking is not performed with respect to the object. A null DACL should not be confused with an empty DACL. An empty DACL is a properly allocated and initialized DACL that contains no ACEs. An empty DACL grants no access to the object it is assigned to.
Objects that have null DACLs can have their security descriptors altered by malicious users so that no one has access to the object.
Even if everyone needs access to an object, the object should be secured so that only administrators can alter its security. If only the creator needs access to an object, a DACL should not be set on the object; the system will choose an appropriate default.
</description>
</rule>
<rule>
<key>C6250</key>
<configkey>C6250</configkey>
<priority>CRITICAL</priority>
<name>warning C6250: Calling <function> VirtualFree without the MEM_RELEASE flag may free memory but not address descriptors (VADs); results in address space leaks</name>
<description>
This warning indicates that a call to VirtualFree without the MEM_RELEASE flag only decommits the pages, and does not release them. To decommit and release pages, use MEM_RELEASE flag in call to VirtualFree. If any pages in the region are committed, the function first decommits and then releases them. After this operation, the pages are in the free state. If you specify this flag, dwSize must be zero, and lpAddress must point to the base address returned by the VirtualAlloc function when the region was reserved. The function fails if either of these conditions is not met.
You can ignore this warning if your code later frees the address space by calling VirtualFree with the MEM_RELEASE flag.
For more information see VirtualAlloc and VirtualFree.
The use of VirtualAlloc and VirtualFree have many pitfalls in terms of memory leaks and exceptions. To avoid these kinds of leaks and exception problems altogether, use the mechanisms that are provided by the C++ Standard Template Library (STL). These include shared_ptr, unique_ptr, and vector. For more information, see Smart Pointers (Modern C++) and Standard C++ Library Reference.
</description>
</rule>
<rule>
<key>C6255</key>
<configkey>C6255</configkey>
<priority>CRITICAL</priority>
<name>warning C6255: _alloca indicates failure by raising a stack overflow exception. Consider using _malloca instead</name>
<description>
This warning indicates that a call to _alloca has been detected outside of local exception handling. _alloca should always be called from within the protected range of an exception handler because it can raise a stack overflow exception on failure. If possible, instead of using _alloca, consider using _malloca which is a more secure version of _alloca.
</description>
</rule>
<rule>
<key>C6258</key>
<configkey>C6258</configkey>
<priority>CRITICAL</priority>
<name>warning C6258: using TerminateThread does not allow proper thread clean up.</name>
<description>
This warning indicates that a call to TerminateThread has been detected.
TerminateThread is a dangerous function that should only be used in the most extreme cases. For more information about problems associated with TerminateThread call, see this topic in the MSDN Library: TerminateThread.
To properly terminate threads
- Create an event object using the CreateEvent function.
- Create the threads.
- Each thread monitors the event state by calling the WaitForSingleObject function.
- Each thread ends its own execution when the event is set to the signaled state (WaitForSingleObject returns WAIT_OBJECT_0).
</description>
</rule>
<rule>
<key>C6259</key>
<configkey>C6259</configkey>
<priority>CRITICAL</priority>
<name>warning C6259: labeled code is unreachable: (<expression> & <constant>) in switch-expr cannot evaluate to <case-label></name>
<description>
This warning indicates unreachable code caused by the result of a bitwise-AND (&) comparison in a switch expression. The case statement that matches the constant in the switch expression is only reachable; all other case statements are not reachable.
</description>
</rule>
<rule>
<key>C6260</key>
<configkey>C6260</configkey>
<priority>CRITICAL</priority>
<name>warning C6260: sizeof * sizeof is almost always wrong, did you intend to use a character count or a byte count?</name>
<description>
This warning indicates that the results of two sizeof operations have been multiplied together. The C/C++ sizeof operator returns the number of bytes of storage an object uses. It is typically incorrect to multiply it by another sizeof operation; usually one is interested in the number of bytes in an object or the number of elements in an array (for example the number of wide-characters in an array).
There is some unintuitive behavior associated with sizeof operator. For example, in C, the sizeof ('\0') == 4, because a character is of an integral type. In C++, the type of a character literal is char, so sizeof ('\0') == 1.
</description>
</rule>
<rule>
<key>C6262</key>
<configkey>C6262</configkey>
<priority>CRITICAL</priority>
<name>warning C6262: Function uses <constant> bytes of stack: exceeds /analyze:stacksize<constant 2>. Consider moving some data to heap</name>
<description>
This warning indicates that stack usage that exceeds a preset threshold (constant 2) has been detected in a function. The default stack frame size for this warning is 16 KB for user mode, 1 KB for kernel mode. Stack—even in user mode—is limited, and failure to commit a page of stack causes a stack overflow exception. Kernel mode has a 12 KB stack size limit, which cannot be increased; therefore, kernel-mode code should aggressively limit stack use.
To correct the problem behind this warning, you can either move some data to the heap or to other dynamic memory. In user mode, one large stack frame may not be a problem—and this warning may be suppressed—but a large stack frame increases the risk of a stack overflow. (A large stack frame might occur if the function uses the stack heavily or is recursive.) The total stack size in user mode can be increased if stack overflow actually occurs, but only up to the system limit. You can use the /analyze command-line option to change the value for <constant 2>, but increasing it introduces a risk that an error will not be reported.
For kernel-mode code—for example, in driver projects—the value of <constant 2> is set to 1 KB. Well-written drivers should have very few functions that approach this value, and changing the limit downward may be desirable. The same general techniques that are used for user-mode code to reduce the stack size can be adapted to kernel-mode code.
</description>
</rule>
<rule>
<key>C6263</key>
<configkey>C6263</configkey>
<priority>CRITICAL</priority>
<name>warning C6263: using _alloca in a loop; this can quickly overflow stack</name>
<description>
This warning indicates that calling _alloca inside a loop to allocate memory can cause stack overflow. _alloca allocates memory from the stack, but that memory is only freed when the calling function exits. Stack, even in user-mode, is limited, and failure to commit a page of stack causes a stack overflow exception. The _resetstkoflw function recovers from a stack overflow condition, allowing a program to continue instead of failing with a fatal exception error. If the _resetstkoflw function is not called, there is no guard page after the previous exception. The next time that there is a stack overflow, there are no exceptions at all and the process terminates without warning.
You should avoid calling _alloca inside a loop if either the allocation size or the iteration count is unknown because it might cause stack overflow. In these cases, consider other options such as, heap memory, or Standard C++ Library Reference classes.
</description>
</rule>
<rule>
<key>C6268</key>
<configkey>C6268</configkey>
<priority>CRITICAL</priority>
<name>warning C6268: Incorrect order of operations: (<TYPE1>)(<TYPE2>)x + y. Possible missing parentheses in (<TYPE1>)((<TYPE2>)x + y)</name>
<description>
This warning indicates that a complex cast expression might involve a precedence problem when performing pointer arithmetic. Because casts group more closely than binary operators, the result might not be what the programmer intended. In some cases, this defect causes incorrect behavior or a program crash.
In an expression such as:
(char *)p + offset
the offset is interpreted as an offset in characters; however, an expression such as:
(int *)(char *)p + offset
is equivalent to:
((int *)(char *)p) + offset
and so the offset is interpreted as an offset in integers. In other words, it is equivalent to:
(int *)((char *)p + (offset * sizeof(int)))
which is not likely to be what the programmer intended.
Depending on the relative sizes of the two types, this can lead to a buffer overrun.
</description>
</rule>
<rule>
<key>C6269</key>
<configkey>C6269</configkey>
<priority>CRITICAL</priority>
<name>warning C6269: possible incorrect order of operations: dereference ignored</name>
<description>
This warning indicates that the result of a pointer dereference is being ignored, which raises the question of why the pointer is being dereferenced in the first place.
The compiler will correctly optimize away the gratuitous dereference. In some cases, however, this defect may reflect a precedence or logic error.
One common cause for this defect is an expression statement of the form: *p++;
If the intent of this statement is simply to increment the pointer p, then dereference is unnecessary; however, if the intent is to increment the location that p is pointing to, then the program will not behave as intended because *p++ construct is interpreted as * (p++). instead of (*p)++.
</description>
</rule>
<rule>
<key>C6270</key>
<configkey>C6270</configkey>
<priority>CRITICAL</priority>
<name>warning C6270: missing float argument to <function>: add a float argument corresponding to conversion specifier <number></name>
<description>
This warning indicates that not enough arguments are being provided to match a format string; at least one of the missing arguments is a floating-point number. This defect can lead to crashes, in addition to potentially incorrect output
</description>
</rule>
<rule>
<key>C6271</key>
<configkey>C6271</configkey>
<priority>CRITICAL</priority>
<name>warning C6271: extra argument passed to <function>: parameter <number> is not used by the format string</name>
<description>
This warning indicates that additional arguments are being provided beyond those specified by the format string. By itself, this defect will not have any visible effect although it indicates that the programmer's intent is not reflected in the code.
</description>
</rule>
<rule>
<key>C6272</key>
<configkey>C6272</configkey>
<priority>CRITICAL</priority>
<name>warning C6272: non-float passed as argument <number> when float is required in call to <function></name>
<description>
This warning indicates that the format string specifies that a float is required, for example, a %f or %g specification for printf, but a non-float such as an integer or string is being passed. This defect is likely to result in incorrect output; however, in certain circumstances it could result in a crash.
</description>
</rule>
<rule>
<key>C6273</key>
<configkey>C6273</configkey>
<priority>CRITICAL</priority>
<name>warning C6273 - non-integer passed as parameter <number> when integer is required in call to <function>: if a pointer value is being passed, %p should be used</name>
<description>
This warning indicates that the format string specifies an integer, for example, a %d, length or precedence specification for printf but a non-integer such as a float, string, or struct is being passed as a parameter. This defect is likely to result in incorrect output.
</description>
</rule>
<rule>
<key>C6274</key>
<configkey>C6274</configkey>
<priority>CRITICAL</priority>
<name>warning C6274: non-character passed as parameter <number> when character is required in call to <function></name>
<description>
This warning indicates that the format string specifies that a character is required (for example, a %c or %C specification) but a non-integer such as a float, string, or struct is being passed. This defect is likely to cause incorrect output.
</description>
</rule>
<rule>
<key>C6276</key>
<configkey>C6276</configkey>
<priority>CRITICAL</priority>
<name>warning C6276: Cast between semantically different string types: char* to wchar_t*. Use of invalid string can lead to undefined behavior</name>
<description>
This warning indicates a potentially incorrect cast from an ANSI string (char_t*) to a UNICODE string (wchar_t *). Because UNICODE strings have a character size of 2 bytes, this cast might yield strings that are not correctly terminated. Using such strings with the wcs* library of functions could cause buffer overruns and access violations
</description>
</rule>
<rule>
<key>C6277</key>
<configkey>C6277</configkey>
<priority>CRITICAL</priority>
<name>warning C6277: NULL application name with an unquoted path in call to <function>: results in a security vulnerability if the path contains spaces</name>
<description>
This warning indicates that the application name parameter is null and there might be spaces in the executable path name. In this case, unless the executable name is "fully qualified," there is likely to be a security problem. A malicious user might insert a rogue executable with the same name earlier in the path. To correct this warning, you can specify the application name instead of passing null or if you do pass null for the application name, use quotation marks around the executable path.
</description>
</rule>
<rule>
<key>C6278</key>
<configkey>C6278</configkey>
<priority>CRITICAL</priority>
<name>warning C6278: <variable> is allocated with array new [], but deleted with scalar delete. Destructors will not be called</name>
<description>
This warning appears only in C++ code and indicates that the calling function has inconsistently allocated memory with the array new [] operator, but freed it with the scalar delete operator. This is undefined behavior according to the C++ standard and the Microsoft Visual C++ implementation. There are at least three reasons that this is likely to cause problems:
- The constructors for the individual objects in the array are invoked, but the destructors are not invoked.
- If global, or class-specific, operator new and operator delete are not compatible with operator new[] and operator delete[], unexpected results are likely to occur.
- It is always very risky to rely on undefined behavior.
The exact ramifications of this defect are difficult to predict. It might result in leaks for classes with destructors that perform memory de-allocation; inconsistent behavior for classes with destructors that perform some semantically significant operation; or memory corruptions and crashes when operators have been overridden. In other cases the mismatch might be unimportant, depending on the implementation of the compiler and its libraries. Analysis tool cannot always distinguish between these situations.
If memory is allocated with array new [], it should be typically be freed with array delete[].
</description>
</rule>
<rule>
<key>C6279</key>
<configkey>C6279</configkey>
<priority>CRITICAL</priority>
<name>warning C6279: <variable> is allocated with scalar new, deleted with array delete [] </name>
<description>
This warning appears only in C++ code and indicates that the calling function has inconsistently allocated memory with the scalar new operator, but freed it with the array delete [] operator. If memory is allocated with scalar new, it should typically be freed with scalar delete.
There are at least three reasons that this is likely to cause problems:
- The constructors for the individual objects in the array are not invoked, although the destructors are.
- If global (or class-specific) operator new and operator delete are not compatible with operator new[] and operator delete[], unexpected results are likely to occur.
The exact ramifications of this defect are difficult to predict. It might cause random behavior or crashes due to usage of uninitialized memory because constructors are not invoked. Or, it might cause memory allocations and crashes in situations where operators have been overridden. In rare cases, the mismatch might be unimportant. Analysis tool does not currently distinguish between these situations.
</description>
</rule>
<rule>
<key>C6280</key>
<configkey>C6280</configkey>
<priority>CRITICAL</priority>
<name>warning C6280: <variable> is allocated with <function>, but deleted with <function></name>
<description>
This warning indicates that the calling function has inconsistently allocated memory by using a function from one memory allocation family and freed it by using a function from another memory allocation family. The analyzer checks for this condition only when the _Analysis_mode_(_Analysis_local_leak_checks_) SAL annotation is specified. By default, this annotation is specified for Windows kernel mode (driver) code. For more information about SAL annotations, see Using SAL Annotations to Reduce C/C++ Code Defects.
For example, this warning would be produced if memory is allocated by using malloc but freed by using GlobalFree or delete. In the specific cases of mismatches between array new[] and scalar delete, more precise warnings are reported instead of this one.
</description>
</rule>
<rule>
<key>C6281</key>
<configkey>C6281</configkey>
<priority>CRITICAL</priority>
<name>warning C6281 - incorrect order of operations: relational operators have higher precedence than bitwise operators</name>
<description>
This warning indicates a possible error in the operator precedence. This might produce incorrect results. You should check the precedence and use parentheses to clarify the intent. Relational operators (<, >, <=, >=, ==, != ) have higher precedence than bitwise operators (& | ^).
</description>
</rule>
<rule>
<key>C6282</key>
<configkey>C6282</configkey>
<priority>CRITICAL</priority>
<name>warning C6282: Incorrect operator: assignment of constant in Boolean context. Consider using '==' instead</name>
<description>
This warning indicates that an assignment of a constant to a variable was detected in a test context. Assignment of a constant to a variable in a test context is almost always incorrect. Replace the = with ==, or remove the assignment from the test context to resolve this warning.
</description>
</rule>
<rule>
<key>C6283</key>
<configkey>C6283</configkey>
<priority>CRITICAL</priority>
<name>warning C6283: <variable> is allocated with array new [], but deleted with scalar delete</name>
<description>
This warning appears only in C++ code and indicates that the calling function has inconsistently allocated memory with the array new [] operator, but freed it with the scalar delete operator. This defect might cause leaks, memory corruptions, and, in situations where operators have been overridden, crashes. If memory is allocated with array new [], it should typically be freed with array delete[].
</description>
</rule>
<rule>
<key>C6284</key>
<configkey>C6284</configkey>
<priority>CRITICAL</priority>
<name>warning C6284: object passed as parameter '%d' when string is required in call to <function>.</name>
<description>
This warning indicates that the format string specifies a string, for example, a %s specification for printf or scanf, but a C++ object has been passed instead.
This defect might produce incorrect output or crashes.
This message is often reported due to passing a C++ object implementing some string type, for example, std::string, CComBSTR or bstr_t, into a C printf-style call. Depending on the implementation of the C++ class, that is, if the proper cast operators are defined, C++ string objects can often be used transparently whenever C strings are required; however, because parameters to printf-style functions are essentially untyped, no conversion to a string occurs.
Depending on the object, it might be appropriate to insert a static_cast operator to the appropriate string type, for example, char * or TCHAR *, or to call a member function which returns a string, for example, c_str(), on instances of std::string.
</description>
</rule>
<rule>
<key>C6285</key>
<configkey>C6285</configkey>
<priority>CRITICAL</priority>
<name>warning C6285: (<non-zero constant> || <non-zero constant>) is always a non-zero constant. Did you intend to use the bitwise-and operator?</name>
<description>
This warning indicates that two constant values, both greater than one, were detected as arguments to a logical-or operation that occurs in a test context. This expression is always TRUE.
Constant values greater than one suggest that the arguments to logical-or could be bit fields. Consider whether a bitwise operator might be a more appropriate operator in this case.
</description>
</rule>
<rule>
<key>C6286</key>
<configkey>C6286</configkey>
<priority>CRITICAL</priority>
<name>warning C6286: (<non-zero constant> || <expression>) is always a non-zero constant. <expression> is never evaluated and may have side effects</name>
<description>
This warning indicates that a non-zero constant was detected on the left side of a logical-or operation that occurs in a test context. The resulting expression always evaluates to TRUE. In addition, the right side of the expression appears to have side effects, and they will be lost.
This warning indicates that you may want to examine the right side of the expression carefully to ensure that any side effects needed for proper functionality are not lost.
The (!0 || <expression>) construction is commonly used to force execution of a controlled block.
</description>
</rule>
<rule>
<key>C6287</key>
<configkey>C6287</configkey>
<priority>CRITICAL</priority>
<name>warning C6287: redundant code: the left and right sub-expressions are identical</name>
<description>
This warning indicates that a redundant element was detected in an expression.
It is difficult to judge the severity of this problem without examining the code. A duplicate test on its own is harmless, but the consequences of deleting the second test can be severe. The code should be inspected to ensure that a test was not omitted.
</description>
</rule>
<rule>
<key>C6288</key>
<configkey>C6288</configkey>
<priority>CRITICAL</priority>
<name>warning C6288: Incorrect operator: mutual inclusion over && is always zero. Did you intent to use || instead?</name>
<description>
This warning indicates that in a test expression, a variable is being tested against two different constants and the result depends on both conditions being true. The code in these cases indicates that the programmer's intent is not captured correctly. It is important to examine the code and correct the problem; otherwise your code will not behave the way you expected it to.
This problem is generally caused by using &&; in place of ||, but can also be caused by using == where != was intended.
</description>
</rule>
<rule>
<key>C6289</key>
<configkey>C6289</configkey>
<priority>CRITICAL</priority>
<name>warning C6289: Incorrect operator: mutual exclusion over || is always a non-zero constant. Did you intend to use && instead?</name>
<description>
This warning indicates that in a test expression a variable is being tested against two different constants and the result depends on either condition being true. This always evaluates to true.
This problem is generally caused by using || in place of &&, but can also be caused by using != where == was intended.
</description>
</rule>
<rule>
<key>C6290</key>
<configkey>C6290</configkey>
<priority>CRITICAL</priority>
<name>warning C6290: Bitwise operation on logical result: ! has higher precedence than &. Use && or (!(x & y)) instead</name>
<description>
This warning indicates possible confusion in the use of an operator or an operator precedence.
The ! operator yields a Boolean result, and it has higher precedence than the &.The bitwise-and (&) operator takes two arithmetic arguments. Therefore, one of the following errors has been detected:
- The expression is mis-parenthesised:
Because the result of ! is Boolean (zero or one), an attempt to test that two variables have bits in common will only end up testing that the lowest bit is present in the right side: ((!8) & 1) == 0.
- The ! operator is incorrect, and should be a ~ instead:
The ! operator has a Boolean result, while the ~ operator has an arithmetic result. These operators are never interchangeable, even when operating on a Boolean value (zero or one): ((!0x01) & 0x10) == 0x0, while ((~0x01) & 0x10) == 0x10.
- The binary operator & is incorrect, and should instead be &&:
While & can sometimes be interchanged with &&, it is not equivalent because it forces evaluation of the right side of the expression. Certain side effects in this type of expression can be terminal.
It is difficult to judge the severity of this problem without examining the code. The code should be inspected to ensure that the intended test is occurring.
</description>
</rule>
<rule>
<key>C6291</key>
<configkey>C6291</configkey>
<priority>CRITICAL</priority>
<name>warning C6291: Bitwise operation on logical result: ! has higher precedence than |. Use || or (!(x | y)) instead</name>
<description>
The ! operator yields a Boolean result, and the | (bitwise-or) operator takes two arithmetic arguments. The ! operator also has higher precedence than |.
Therefore, one of the following errors has been detected:
- The expression is mis-parenthesised:
Because the result of ! is Boolean (zero or one), an attempt to test that two variables have bits set will only end up testing that the lowest bit is present in the right side: ((!x) | y) != (!(x | y)) when x == 0 and y == 1.
- The ! operator is incorrect, and should be a ~ instead:
The ! operator has a Boolean result, but the ~ operator has an arithmetic result. These operators are never interchangeable, even when operating on a Boolean value (zero or one): ((!x) | y) != ((~x) | y) when x == 1 and y == 0.
- The binary operator | is incorrect, and should instead be ||:
Even though | can sometimes be interchanged with ||, it is not equivalent because it forces evaluation of the right side of the expression. Certain side-effects in this type of expression can be terminal: (!p | (*p == '\0')), when p == NULL, we must dereference it to evaluate the other half of the expression.
This warning is not reported if the ! operator is on the right side of the | operator because this case is typically just the relatively harmless case of an incorrect operator.
It is difficult to judge the severity of this problem without examining the code. The code should be inspected to ensure that the intended test is occurring.
This warning always indicates possible confusion in the use of an operator or operator precedence.
</description>
</rule>
<rule>
<key>C6292</key>
<configkey>C6292</configkey>
<priority>CRITICAL</priority>
<name>warning C6292: ill-defined for-loop: counts up from maximum</name>
<description>
This warning indicates that a for-loop might not function as intended.
It occurs when a loop counts up from a maximum, but has a lower termination condition. This loop will terminate only after integer overflow occurs.
</description>
</rule>
<rule>
<key>C6293</key>
<configkey>C6293</configkey>
<priority>CRITICAL</priority>
<name>warning C6293: Ill-defined for-loop: counts down from minimum</name>
<description>
This warning indicates that a for-loop might not function as intended. It occurs when a loop counts down from a minimum, but has a higher termination condition.
A signed —or unsigned—index variable together with a negative increment will cause the loop to count negative until an overflow occurs. This will terminate the loop.
</description>
</rule>
<rule>
<key>C6294</key>
<configkey>C6294</configkey>
<priority>CRITICAL</priority>
<name>warning C6294: Ill-defined for-loop: initial condition does not satisfy test. Loop body not executed</name>
<description>
This warning indicates that a for-loop cannot be executed because the terminating condition is true. This warning suggests that the programmer's intent is not correctly captured.
</description>
</rule>
<rule>
<key>C6295</key>
<configkey>C6295</configkey>
<priority>CRITICAL</priority>
<name>warning C6295: Ill-defined for-loop: <variable> values are of the range "min" to "max". Loop executed indefinitely</name>
<description>
This warning indicates that a for-loop might not function as intended. The for-loop tests an unsigned value against zero (0) with >=. The result is always true, therefore the loop is infinite.
</description>
</rule>
<rule>
<key>C6296</key>
<configkey>C6296</configkey>
<priority>CRITICAL</priority>
<name>warning C6296: Ill-defined for-loop: Loop body only executed once</name>
<description>
This warning indicates that a for-loop might not function as intended. When the index is unsigned and a loop counts down from zero, its body is run only once.
</description>
</rule>
<rule>
<key>C6297</key>
<configkey>C6297</configkey>
<priority>CRITICAL</priority>
<name>warning C6297: Arithmetic overflow: 32-bit value is shifted, then cast to 64-bit value. Result may not be an expected value</name>
<description>
This warning indicates incorrect behavior that results from integral promotion rules and types larger than those in which arithmetic is typically performed.
In this case, a 32-bit value was shifted left, and the result of that shift was cast to a 64-bit value. If the shift overflowed the 32-bit value, bits are lost.
If you do not want to lose bits, cast the value to be shifted to a 64-bit quantity before it is shifted. If you want to lose bits, performing the appropriate cast to unsigned long or a short type, or masking the result of the shift will eliminate this warning and make the intent of the code more clear.
</description>
</rule>
<rule>
<key>C6298</key>
<configkey>C6298</configkey>
<priority>CRITICAL</priority>
<name>warning C6298: using a read-only string <pointer> as a writable string argument: this will attempt to write into static read-only memory and cause random crashes</name>
<description>
This warning indicates the use of a constant string as an argument to a function that might modify the contents of that string. Because the compiler allocates constant strings in a static read-only memory, any attempts to modify it cause access violations and random crashes.
This can be avoided by storing the constant string into a local array and then using the array as the argument to the function.
</description>
</rule>
<rule>
<key>C6299</key>
<configkey>C6299</configkey>
<priority>CRITICAL</priority>
<name>warning C6299: explicitly comparing a bit field to a Boolean type will yield unexpected results</name>
<description>
This warning indicates an incorrect assumption that Booleans and bit fields are equivalent. Assigning 1 to bit fields will place 1 in its single bit; however, any comparison of this bit field to 1 includes an implicit cast of the bit field to a signed int. This cast will convert the stored 1 to a -1 and the comparison can yield unexpected results.
</description>
</rule>
<rule>
<key>C6302</key>
<configkey>C6302</configkey>
<priority>CRITICAL</priority>
<name>warning C6302: format string mismatch: character string passed as parameter <number> when wide character string is required in call to <function></name>
<description>
This warning indicates that the format string specifies that a wide character string is required. However, a character string is being passed. This defect is likely to cause a crash or a corruption of some form.
</description>
</rule>
<rule>
<key>C6303</key>
<configkey>C6303</configkey>
<priority>CRITICAL</priority>
<name>warning C6303: format string mismatch: wide character string passed as parameter <number> when character string is required in call to <function></name>
<description>
This warning indicates that the format string specifies that a character string is required. However, a wide character string is being passed. This defect is likely to cause a crash or corruption of some form.
</description>
</rule>
<rule>
<key>C6305</key>
<configkey>C6305</configkey>
<priority>CRITICAL</priority>
<name>warning C6305: potential mismatch between sizeof and countof quantities</name>
<description>
This warning indicates that a variable holding a sizeof result is being added to or subtracted from a pointer or countof expression. This will cause unexpected scaling in pointer arithmetic.
</description>
</rule>
<rule>
<key>C6306</key>
<configkey>C6306</configkey>
<priority>CRITICAL</priority>
<name>warning C6306: incorrect call to <function>: consider using <function> which accepts a va_list as an argument</name>
<description>
This warning indicates an incorrect function call. The printf family includes several functions that take a variable list of arguments; however, these functions cannot be called with a va_list argument. There is a corresponding vprintf family of functions that can be used for such calls. Calling the wrong print function will cause incorrect output.
</description>
</rule>
<rule>
<key>C6308</key>
<configkey>C6308</configkey>
<priority>CRITICAL</priority>
<name>warning C6308: 'realloc' may return null pointer: assigning a null pointer to <variable>, which is passed as an argument to 'realloc', will cause the original memory block to be leaked</name>
<description>
This warning indicates a memory leak that is the result of the incorrect use of a reallocation function. Heap reallocation functions do not free the passed buffer if reallocation is unsuccessful. To correct the defect, assign the result of the reallocation function to a temporary, and then replace the original pointer after successful reallocation.
</description>
</rule>
<rule>
<key>C6309</key>
<configkey>C6309</configkey>
<priority>CRITICAL</priority>
<name>warning C6309: argument <number> is null: it does not adhere to function specification of <function></name>
<description>
This message indicates that the code is passing an unexpected NULL parameter as an argument to the specified API. Passing a null parameter to a function that expects a non-null parameter can cause unhandled exception.
</description>
</rule>
<rule>
<key>C6310</key>
<configkey>C6310</configkey>
<priority>CRITICAL</priority>
<name>warning C6310: illegal constant in exception filter can cause unexpected behavior</name>
<description>
This message indicates that an illegal constant was detected in the filter expression of a structured exception handler. The constants defined for use in the filter expression of a structured exception handler are:
- EXCEPTION_CONTINUE_EXECUTION
- EXCEPTION_CONTINUE_SEARCH
- EXCEPTION_EXECUTE_HANDLER
These values are defined in the runtime header file excpt.h.
Using a constant that is not in the preceding list can cause unexpected behavior.
</description>
</rule>
<rule>
<key>C6312</key>
<configkey>C6312</configkey>
<priority>CRITICAL</priority>
<name>warning C6312: Possible infinite loop: use of the constant EXCEPTION_CONTINUE_EXECUTION in the exception-filter expression of a try-except</name>
<description>
This warning indicates the use of the constant EXCEPTION_CONTINUE_EXECUTION (or another constant that evaluates to -1) in the filter expression of a structured exception handler. Use of the constant value EXCEPTION_CONTINUE_EXECUTION could lead to an infinite loop. For example, if an exception was raised by hardware, the instruction that caused the exception will be restarted. If the address that caused the exception is still bad, another exception will occur and be handled in the same way. This causes an infinite loop.
An explicit call to RaiseException will not directly cause an infinite loop, but it will continue execution of the code in the protected block. This can be unexpected, and could lead to an infinite loop if RaiseException was used to avoid dereferencing an invalid pointer.
Typically, EXCEPTION_CONTINUE_EXECUTION should be returned only by a function called in the filter expression, which has a chance to fix either the pointer that caused the exception or the underlying memory.
</description>
</rule>
<rule>
<key>C6313</key>
<configkey>C6313</configkey>
<priority>CRITICAL</priority>
<name>warning C6313: Incorrect operator: Zero-valued flag cannot be tested with bitwise-and. Use an equality test to check for zero-valued flags</name>
<description>
This warning indicates that a constant value of zero was provided as an argument to the bitwise-and (&) operator in a test context. The resulting expression is constant and evaluates to false; the result is different than intended.
This is typically caused by using bitwise-and to test for a flag that has the value zero. To test zero-valued flags, a test for equality must be performed, for example, using == or !=.
</description>
</rule>
<rule>
<key>C6314</key>
<configkey>C6314</configkey>
<priority>CRITICAL</priority>
<name>warning C6314: Incorrect order of operations: bitwise-or has higher precedence than the conditional-expression operator. Add parentheses to clarify intent</name>
<description>
This message indicates that an expression that contains a bitwise-or operator (|) was detected in the tested expression of a conditional operation (?:).
The conditional operator has lower precedence than bitwise operators. If the tested expression should contain the bitwise-or operator, then parentheses should be added around the conditional-expression.
</description>
</rule>
<rule>
<key>C6315</key>
<configkey>C6315</configkey>
<priority>CRITICAL</priority>
<name>warning C6315: Incorrect order of operations: bitwise-and has higher precedence than bitwise-or. Add parentheses to clarify intent</name>
<description>
This warning indicates that an expression in a test context contains both bitwise-and (&) and bitwise-or (|) operations, but causes a constant because the bitwise-or operation happens last. Parentheses should be added to clarify intent.
</description>
</rule>
<rule>
<key>C6316</key>
<configkey>C6316</configkey>
<priority>CRITICAL</priority>
<name>warning C6316: Incorrect operator: tested expression is constant and non-zero. Use bitwise-and to determine whether bits are set</name>
<description>
This warning indicates the use of bitwise-or (|) when bitwise-and (&) should have been used. Bitwise-or adds bits to the resulting expression, whereas bitwise-and selects only those bits in common between its two operators. Tests for flags must be performed with bitwise-and or a test of equality.
</description>
</rule>
<rule>
<key>C6317</key>
<configkey>C6317</configkey>
<priority>CRITICAL</priority>
<name>warning C6317: incorrect operator: logical-not (!) is not interchangeable with ones-complement (~)</name>
<description>
This warning indicates that a logical-not (!) is being applied to a constant that is likely to be a bit-flag. The result of logical-not is Boolean; it is incorrect to apply the bitwise-and (&) operator to a Boolean value. Use the ones-complement (~) operator to flip flags.
</description>
</rule>
<rule>
<key>C6318</key>
<configkey>C6318</configkey>
<priority>CRITICAL</priority>
<name>warning C6318: Ill-defined __try/__except: use of the constant EXCEPTION_CONTINUE_SEARCH. The code in the exception handler block is not executed</name>
<description>
warning C6318: Ill-defined __try/__except: use of the constant EXCEPTION_CONTINUE_SEARCH or another constant that evaluates to zero in the exception-filter expression. The code in the exception handler block is not executed
This warning indicates that if an exception occurs in the protected block of this structured exception handler, the exception will not be handled because the constant EXCECPTION_CONTINUE_SEARCH is used in the exception filter expression.
This code is equivalent to the protected block without the exception handler block because the handler block is not executed.
</description>
</rule>
<rule>
<key>C6319</key>
<configkey>C6319</configkey>
<priority>CRITICAL</priority>
<name>warning C6319: use of the comma-operator in a tested expression causes the left argument to be ignored when it has no side-effects</name>
<description>
This warning indicates an ignored sub-expression in test context because of the comma-operator (,). The comma operator has left-to-right associativity. The result of the comma-operator is the last expression evaluated. If the left expression to comma-operator has no side effects, the compiler might omit code generation for the expression.
</description>
</rule>
<rule>
<key>C6320</key>
<configkey>C6320</configkey>
<priority>CRITICAL</priority>
<name>warning C6320: exception-filter expression is the constant EXCEPTION_EXECUTE_HANDLER. This may mask exceptions that were not intended to be handled</name>
<description>
This warning indicates the side effect of using EXCEPTION_EXECUTE_HANDLER constant in __except block. In this case, the statement in the __except block will always execute to handle the exception, including exceptions you did not want to handle in a particular function. It is recommended that you check the exception before handling it.
</description>
</rule>
<rule>
<key>C6322</key>
<configkey>C6322</configkey>
<priority>CRITICAL</priority>
<name>warning C6322: empty _except block</name>
<description>
This message indicates that there is no code in the _except block. As a result, exceptions might go unhandled.
</description>
</rule>
<rule>
<key>C6323</key>
<configkey>C6323</configkey>
<priority>CRITICAL</priority>
<name>warning C6323 - use of arithmetic operator on Boolean type(s)</name>
<description>
This warning occurs if arithmetic operators are used on Boolean data types. Use of incorrect operator might yield incorrect results. It also indicates that the programmer's intent is not reflected in the code.
</description>
</rule>
<rule>
<key>C6324</key>
<configkey>C6324</configkey>
<priority>CRITICAL</priority>
<name>warning C6324: potential incorrect use of <function1>: Did you intend to use <function2>?</name>
<description>
This warning indicates that a string copy function was used where a string comparison function should have been used. Incorrect use of function can cause an unexpected logic error.
</description>
</rule>
<rule>
<key>C6326</key>
<configkey>C6326</configkey>
<priority>CRITICAL</priority>
<name>warning C6326: potential comparison of a constant with another constant</name>
<description>
This warning indicates a potential comparison of a constant with another constant, which is redundant code. You must check to make sure that your intent is properly captured in the code. In some cases, you can simplify the test condition to achieve the same result.
</description>
</rule>
<rule>
<key>C6327</key>
<configkey>C6327</configkey>
<priority>CRITICAL</priority>
<name>warning C6327: Potential buffer overrun: SysAllocStringLen copies <number> characters from the string <variable> without validating the number of characters to copy. The code may crash</name>
<description>
This warning indicates a potential buffer overrun. SysAllocStringLen allocates a string and then copies the specified number of characters from the specified string. Because SysAllocStringLen does not validate the number of characters to copy, if the number of characters specified is larger than the number of characters in the string, the code might crash. You must pass correct number of characters to the SysAllocString function to avoid buffer overrun.
</description>
</rule>
<rule>
<key>C6328</key>
<configkey>C6328</configkey>
<priority>CRITICAL</priority>
<name>warning C6328: Size mismatch: <type> passed as parameter <number> when <type> is required in call to <function></name>
<description>
For C runtime character-based routines in the family name isxxx(), passing an argument of type char can have unpredictable results. For example, an SBCS or MBCS single-byte character of type char with a value greater than 0x7F is a negative value. If a char is passed, the compiler might convert the value to a signed int or a signed long. This value could be sign-extended by the compiler, with unexpected results. For example, isspace accepts an argument of type int; however, the valid range of values for its input argument is:
0 <= c <= 255, plus the special value EOF.
</description>
</rule>
<rule>
<key>C6329</key>
<configkey>C6329</configkey>
<priority>CRITICAL</priority>
<name>warning C6329: Return value for a call to <function> should not be checked against <number></name>
<description>
The program is comparing a number against the return value from a call to CreateFile. If CreateFile succeeds, it returns an open handle to the object. If it fails, it returns INVALID_HANDLE_VALUE.
</description>
</rule>
<rule>
<key>C6330</key>
<configkey>C6330</configkey>
<priority>CRITICAL</priority>
<name>warning C6330: Incorrect type passed as parameter in call to function</name>
<description>
warning C6330: Incorrect type passed as parameter in call to function
</description>
</rule>
<rule>
<key>C6331</key>
<configkey>C6331</configkey>
<priority>CRITICAL</priority>
<name>warning C6331: Invalid parameter: passing MEM_RELEASE and MEM_DECOMMIT in conjunction to <function> is not allowed. This results in the failure of this call</name>
<description>
This message indicates that an invalid parameter being passed to VirtualFree or VirtualFreeEx. VirtualFree and VirtualFreeEx both reject the flags (MEM_RELEASE | MEM_DECOMMIT) in combination. Therefore, the values MEM_DECOMMIT and MEM_RELEASE may not be used together in the same call.
It is not required for decommit and release to occur as independent steps. Releasing committed memory will decommit the pages as well. Also, ensure the return value of this function is not ignored.
</description>
</rule>
<rule>
<key>C6332</key>
<configkey>C6332</configkey>
<priority>CRITICAL</priority>
<name>warning C6332: Invalid parameter: passing zero as the dwFreeType parameter to <function> is not allowed. This results in the failure of this call</name>
<description>
This warning indicates that an invalid parameter is being passed to VirtualFree or VirtualFreeEx. VirtualFree and VirtualFreeEx both reject a dwFreeType parameter of zero. The dwFreeType parameter can be either MEM_DECOMMIT or MEM_RELEASE. However, the values MEM_DECOMMIT and MEM_RELEASE may not be used together in the same call. Also, make sure that the return value of the VirtualFree function is not ignored.
</description>
</rule>
<rule>
<key>C6333</key>
<configkey>C6333</configkey>
<priority>CRITICAL</priority>
<name>warning C6333: Invalid parameter: passing MEM_RELEASE and a non-zero dwSize parameter to <function> is not allowed. This results in the failure of this call</name>
<description>
This warning indicates an invalid parameter is being passed to VirtualFree or VirtualFreeEx. Both of these functions reject a dwFreeType of MEM_RELEASE with a non-zero value of dwSize. When passing MEM_RELEASE, the dwSize parameter must be zero. Also, make sure that the return value of this function is not ignored.
</description>
</rule>
<rule>
<key>C6334</key>
<configkey>C6334</configkey>
<priority>CRITICAL</priority>
<name>warning C6334: sizeof operator applied to an expression with an operator may yield unexpected results</name>
<description>
This warning indicates a misuse of the sizeof operator. The sizeof operator, when applied to an expression, yields the size of the type of the resulting expression.
</description>
</rule>
<rule>
<key>C6335</key>
<configkey>C6335</configkey>
<priority>CRITICAL</priority>
<name>warning C6335: leaking process information handle <handlename></name>
<description>
This warning indicates that the process information handles returned by the CreateProcess family of functions need to be closed using CloseHandle. Failure to do so will cause handle leaks.
</description>
</rule>
<rule>
<key>C6336</key>
<configkey>C6336</configkey>
<priority>CRITICAL</priority>
<name>warning C6336: arithmetic operator has precedence over question operator, use parentheses to clarify intent</name>
<description>
This warning indicates a possible operator precedence problem. The '+','-','*' and '/' operators have precedence over the '?' operator. If the precedence in the expression is not correct, use parentheses to change the operator precedence.
</description>
</rule>
<rule>
<key>C6340</key>
<configkey>C6340</configkey>
<priority>CRITICAL</priority>
<name>warning C6340: Mismatch on sign: Incorrect type passed as parameter in call to function</name>
<description>
warning C6340: Mismatch on sign: Incorrect type passed as parameter in call to function
</description>
</rule>
<rule>
<key>C6381</key>
<configkey>C6381</configkey>
<priority>CRITICAL</priority>
<name>warning C6381: Shutdown API <function> requires a valid dwReason or lpMessage</name>
<description>
This warning is issued if InitiateSystemShutdownEx is called:
- Without passing a valid shutdown reason (dwReason). If dwReason parameter is zero, the default is an undefined shutdown. By default, it is also an unplanned shutdown. You should use one of the System Shutdown Reason Codes for this parameter.
- Without passing a shutdown message (lpMessage).
We recommend that you use appropriate parameters when calling this API to help system administrators determine the cause of the shutdown.
</description>
</rule>
<rule>
<key>C6383</key>
<configkey>C6383</configkey>
<priority>CRITICAL</priority>
<name>warning C6383: buffer overrun due to conversion of an element count into a byte count: an element count is expected for parameter <number> in call to <function></name>
<description>
This warning indicates that a non-constant byte count is being passed when an element count is required. Typically, this occurs when a variable is multiplied by the sizeof a type, but code analysis suggests that an element count is required.
</description>
</rule>
<rule>
<key>C6384</key>
<configkey>C6384</configkey>
<priority>CRITICAL</priority>
<name>warning C6384: dividing sizeof a pointer by another value</name>
<description>
This warning indicates that a size calculation might be incorrect. To calculate the number of elements in an array, one sometimes divides the size of the array by the size of the first element; however, when the array is actually a pointer, the result is typically different than intended.
If the pointer is a function parameter and the size of the buffer was not passed, it is not possible to calculate the maximum buffer available. When the pointer is allocated locally, the size used in the allocation should be used.
</description>
</rule>
<rule>
<key>C6385</key>
<configkey>C6385</configkey>
<priority>CRITICAL</priority>
<name>warning C6385: invalid data: accessing <buffer name>, the readable size is <size1> bytes, but <size2> bytes may be read: Lines: x, y</name>
<description>
This warning indicates that the readable extent of the specified buffer might be smaller than the index used to read from it. Attempts to read data outside the valid range leads to buffer overrun.
</description>
</rule>
<rule>
<key>C6386</key>
<configkey>C6386</configkey>
<priority>CRITICAL</priority>
<name>warning C6386: buffer overrun: accessing <buffer name>, the writable size is <size1> bytes, but <size2> bytes may be written: Lines: x, y</name>
<description>
This warning indicates that the writable extent of the specified buffer might be smaller than the index used to write to it. This can cause buffer overrun.
</description>
</rule>
<rule>
<key>C6387</key>
<configkey>C6387</configkey>
<priority>CRITICAL</priority>
<name>warning C6387: <argument> may be <value>: this does not adhere to the specification for the function <function name>: Lines: x, y</name>
<description>
This warning is raised if an annotated function parameter is being passed an unexpected value. For example, passing a potentially null value to a parameter that is marked with _In_ annotation generates this warning.
</description>
</rule>
<rule>
<key>C6388</key>
<configkey>C6388</configkey>
<priority>CRITICAL</priority>
<name>warning C6388: <argument> may not be <value>: this does not adhere to the specification for the function <function name>: Lines: x, y</name>
<description>
This warning indicates that an unexpected value is being used in the specified context. This is typically reported for values passed as arguments to a function that does not expect it.
</description>
</rule>
<rule>
<key>C6400</key>
<configkey>C6400</configkey>
<priority>CRITICAL</priority>
<name>warning C6400: Using <function name> to perform a case-insensitive compare to constant string <string name>. Yields unexpected results in non-English locales</name>
<description>
This warning indicates that a case-insensitive comparison to a constant string is being performed in a locale-dependent way, when, apparently, a locale-independent comparison was intended.
The typical consequence of this defect is incorrect behavior in non-English speaking locales. For example, in Turkish, ".gif" will not match ".GIF"; in Vietnamese, "LogIn" will not match "LOGIN".
String comparisons should typically be performed with the CompareString function. To perform a locale-independent comparison on Windows XP, the first parameter should be the constant LOCALE_INVARIANT.
</description>
</rule>
<rule>
<key>C6401</key>
<configkey>C6401</configkey>
<priority>CRITICAL</priority>
<name>warning C6401: Using <function name> in a default locale to perform a case-insensitive compare to constant string < string name>. Yields unexpected results in non-English locales</name>
<description>
This warning indicates that a case-insensitive comparison to a constant string is being performed when specifying the default locale; usually, a locale-independent comparison was intended.
The typical consequence of this defect is incorrect behavior in non-English speaking locales. For example, in Turkish, ".gif" will not match ".GIF"; in Vietnamese, "LogIn" will not match "LOGIN".
The CompareString function takes a locale as an argument; however, passing in a default locale, for example, the constant LOCALE_USER_DEFAULT, will cause different behaviors in different locales, depending on the user's default. Usually, case-insensitive comparisons against a constant string should be performed in a locale-independent comparison.
</description>
</rule>
<rule>
<key>C6411</key>
<configkey>C6411</configkey>
<priority>CRITICAL</priority>
<name>Warning C6411: Potentially reading invalid data from the buffer.</name>
<description>
This warning indicates that the value of the index that is used to read from the buffer can exceed the readable size of the buffer. Because the code analysis tool reports this warning when it cannot reduce a complex expression that represents the buffer size, or the index used to access the buffer, this warning might be reported in error.
</description>
</rule>
<rule>
<key>C6412</key>
<configkey>C6412</configkey>
<priority>CRITICAL</priority>
<name>warning C6412: Potential buffer overrun while writing to buffer. The writable size is write_size bytes, but write_index bytes may be written.</name>
<description>
This warning indicates that the value of the index that is used to write to the buffer can exceed the writeable size of the buffer.
Because the code analysis tool reports this warning when it cannot reduce a complex expression that represents the buffer size, or the index used to access the buffer, this warning might be reported in error.
</description>
</rule>
<rule>
<key>C6500</key>
<configkey>C6500</configkey>
<priority>CRITICAL</priority>
<name>warning C6500: invalid annotation: value for <name> property is invalid</name>
<description>
This warning indicates that a property value used in the annotation is not valid. For example, it can occur if an incorrect level of dereference is used in the Deref property, or if you use a constant value that is larger than size_t for properties like ElementSize.
</description>
</rule>
<rule>
<key>C6501</key>
<configkey>C6501</configkey>
<priority>CRITICAL</priority>
<name>warning C6501: annotation conflict: <name> property conflicts with previously specified property</name>
<description>
This warning indicates the presence of conflicting properties in the annotation. This typically occurs when multiple properties that serve similar purpose are used to annotate a parameter or return value. To correct the warning, you must choose the property that best addresses your need.
</description>
</rule>
<rule>
<key>C6503</key>
<configkey>C6503</configkey>
<priority>CRITICAL</priority>
<name>warning C6503: Invalid annotation: references and arrays may not be marked Null=Yes or Null=Maybe</name>
<description>
This warning indicates that Null property is incorrectly used on a reference or array type. A reference or array type holds the address of an object and must point to a valid object. Because reference and array types cannot be null, you must correct the error by either removing the Null property or by setting the Null property value to No.
</description>
</rule>
<rule>
<key>C6504</key>
<configkey>C6504</configkey>
<priority>CRITICAL</priority>
<name>warning C6504: invalid annotation: property may only be used on values of pointer, pointer-to-member, or array type</name>
<description>
This warning indicates the use of a property on an incompatible data type. For more information about data types supported by properties, see [NIB]Annotation Properties.
</description>
</rule>
<rule>
<key>C6505</key>
<configkey>C6505</configkey>
<priority>CRITICAL</priority>
<name>warning C6505: invalid annotation: MustCheck property may not be used on values of void type</name>
<description>
This warning indicated that MustCheck property was used on a void data type. You cannot use MustCheck property on void type. Either remove the MustCheck property or use another data type.
</description>
</rule>
<rule>
<key>C6506</key>
<configkey>C6506</configkey>
<priority>CRITICAL</priority>
<name>warning C6506: invalid annotation: <name> property may only be used on values of pointer or array types</name>
<description>
This warning indicates that a property is used on a type other than pointer or array types. The Access, Tainted, and Valid properties can be used on all data types. Other properties, such as ValidBytesConst, ValidElementsConst, ElementSize, and NullTerminted support pointer, pointer to members, or array types. For a complete list of properties and the supported data types, see [NIB]Annotation Properties.
</description>
</rule>
<rule>
<key>C6507</key>
<configkey>C6507</configkey>
<priority>CRITICAL</priority>
<name>warning C6507: annotation conflict: Null property at Deref=0 on a post condition must be a subset of the Null property on the precondition</name>
<description>
This warning indicates that conflicting values for the Null property were used in Pre- and Post- conditions at default dereference level 0. In this case the Pre condition specifies Null=No, and the Post condition specifies Null=Yes. Because the parameter is not passed by reference it cannot be changed; therefore, the Post condition cannot use Null=Yes.
</description>
</rule>
<rule>
<key>C6508</key>
<configkey>C6508</configkey>
<priority>CRITICAL</priority>
<name>warning C6508: invalid annotation: write access is not allowed on const values</name>
<description>
This warning indicates that the Access property specified on a const parameter implies that it can be written to. For constant values, Access=Read is the only valid setting.
</description>
</rule>
<rule>
<key>C6509</key>
<configkey>C6509</configkey>
<priority>CRITICAL</priority>
<name>warning C6509: invalid annotation: 'return' cannot be referenced from a precondition</name>
<description>
This warning indicates that the return keyword cannot be used in a precondition. The return keyword is used to terminate the execution of a function and return control to the calling function.
</description>
</rule>
<rule>
<key>C6510</key>
<configkey>C6510</configkey>
<priority>CRITICAL</priority>
<name>warning C6510: Invalid annotation: 'NullTerminated' property may only be used on buffers whose elements are of integral or pointer type: Function '<function>' <parameter>.</name>
<description>
This warning indicates an incorrect use of the NullTerminated property (those ending in '_z'). You can only use this type of property on pointer or array types.
</description>
</rule>
<rule>
<key>C6511</key>
<configkey>C6511</configkey>
<priority>CRITICAL</priority>
<name>warning C6511: invalid annotation: MustCheck property must be Yes or No</name>
<description>
This warning indicates an invalid value for MustCheck property was specified. The only valid values for this property are: Yes and No.
</description>
</rule>
<rule>
<key>C6512</key>
<configkey>C6512</configkey>
<priority>CRITICAL</priority>
<name>warning C6512: invalid annotation: Null property must be Maybe if the Valid property is No</name>
<description>
This warning indicates that Null is considered a valid value; therefore, Null cannot be used with the Valid property value of No.
</description>
</rule>
<rule>
<key>C6513</key>
<configkey>C6513</configkey>
<priority>CRITICAL</priority>
<name>warning C6513: invalid annotation: ElementSizeConst requires additional size properties</name>
<description>
This warning indicates that ElementSizeConst requires other properties that are missing from the annotation. Specifying ElementSizeConst alone does not provide any benefit to the analysis process. In addition to specifying ElementSize, other properties such as ValidElementsConst or WritableElementsConst must also be specified.
</description>
</rule>
<rule>
<key>C6514</key>
<configkey>C6514</configkey>
<priority>CRITICAL</priority>
<name>warning C6514: invalid annotation: value of the <name> property exceeds the size of the array</name>
<description>
This warning indicates that a property value exceeds the size of the array specified in the parameter being annotated. This warning occurs when the value specified for the annotation property is greater than the actual length of the array being passed.
</description>
</rule>
<rule>
<key>C6515</key>
<configkey>C6515</configkey>
<priority>CRITICAL</priority>
<name>warning C6515 - invalid annotation: <name> property may only be used on values of pointer type</name>
<description>
This warning indicates that a property for use on pointers was applied to a non-pointer type. For a list of annotation properties, see [NIB]Annotation Properties.
</description>
</rule>
<rule>
<key>C6516</key>
<configkey>C6516</configkey>
<priority>CRITICAL</priority>
<name>warning C6516: invalid annotation: no properties specified for <name> attribute</name>
<description>
This warning indicates that either no property was specified in the attribute or the property that was specified is invalid; therefore, the attribute cannot be considered complete.
</description>
</rule>
<rule>
<key>C6517</key>
<configkey>C6517</configkey>
<priority>CRITICAL</priority>
<name>warning C6517: Invalid annotation: 'SAL_readableTo' property may not be specified on buffers that are not readable: '_Param_(1)'.</name>
<description>
This warning indicates that SAL_readableTo property does not have the required read access. You cannot use this property to annotate a parameter without providing read access.
</description>
</rule>
<rule>
<key>C6518</key>
<configkey>C6518</configkey>
<priority>CRITICAL</priority>
<name>warning C6518: Invalid annotation: 'SAL_writableTo' property may not be specified as a precondition on buffers that are not writable: '_Param_(1)'</name>
<description>
This warning indicates that a conflict exists between a SAL_writableTo property value and a writable property. This ordinarily indicates that a writable property does not have write access to the parameter being annotated.
</description>
</rule>
<rule>
<key>C6521</key>
<configkey>C6521</configkey>
<priority>CRITICAL</priority>
<name>warning C6521: invalid size specification: * operator can only be applied to pointer types</name>
<description>
This warning indicates an incorrect use of the * operator in an annotation property that accepts the size of a parameter in terms of another parameter. This warning is generated if the size parameter is a non-pointer type and a * operator is used to dereference it. However, you can use the * operator if the size parameter is passed as pointer type.
</description>
</rule><rule>
<key>C6522</key>
<configkey>C6522</configkey>
<priority>CRITICAL</priority>
<name>warning C6522: invalid size specification: expression must be of integral type</name>
<description>
This warning indicates that an integral type was expected, but an incorrect data type was used. You can use annotation properties that accept the size of a parameter in terms of another parameter, but you must use correct data type. For a list of annotation properties, see [NIB]Annotation Properties.
</description>
</rule>
<rule>
<key>C6523</key>
<configkey>C6523</configkey>
<priority>CRITICAL</priority>
<name>warning C6523: invalid size specification: parameter <name> not found</name>
<description>
This warning indicates that a parameter used to set a property value is not in the function parameter list. You can use annotation properties that accept the name of a parameter as their value, but you must make sure that the parameter exists and is of the correct data type.
</description>
</rule>
<rule>
<key>C6525</key>
<configkey>C6525</configkey>
<priority>CRITICAL</priority>
<name>warning C6525: invalid size specification: property value may not be valid</name>
<description>
This warning indicates that the property value used to specify the size is not valid. This occurs if the size parameter is annotated using Valid=No.
</description>
</rule>
<rule>
<key>C6526</key>
<configkey>C6526</configkey>
<priority>CRITICAL</priority>
<name>warning C6526 - invalid size specification: expression must be of array or pointer type</name>
<description>
This warning indicates that an incorrect data type is used to specify a property value. A property might support all data types or a subset of them. In this case, the value specified for the property must be an array or a pointer type. For a list of annotation properties, see Annotation Properties.
</description>
</rule>
<rule>
<key>C6527</key>
<configkey>C6527</configkey>
<priority>CRITICAL</priority>
<name>warning C6527: Invalid annotation: NeedsRelease property may not be used on values of void type</name>
<description>
warning C6527: Invalid annotation: NeedsRelease property may not be used on values of void type
</description>
</rule>
<rule>
<key>C6530</key>
<configkey>C6530</configkey>
<priority>CRITICAL</priority>
<name>warning C6530: unrecognized format string style <name></name>
<description>
This warning indicates that the FormatString property is using a value other than scanf or printf. To correct this warning, review your code and use a valid value for the Style property.
</description>
</rule>
<rule>
<key>C6535</key>
<configkey>C6535</configkey>
<priority>CRITICAL</priority>
<name>warning C6535: buffer cannot be of size <n>, bigger than max(size_t)</name>
<description>
This warning indicates that the size of the buffer cannot be more than size_t. The type size_t is defined as an unsigned integer and its actual size is system dependent.
</description>
</rule>
<rule>
<key>C6540</key>
<configkey>C6540</configkey>
<priority>CRITICAL</priority>
<name>warning C6540: The use of attribute annotations on this function will invalidate all of its existing __declspec annotations</name>
<description>
warning C6540: The use of attribute annotations on this function will invalidate all of its existing __declspec annotations
</description>
</rule>
<rule>
<key>C6551</key>
<configkey>C6551</configkey>
<priority>CRITICAL</priority>
<name>warning C6551: Invalid size specification: expression not parsable</name>
<description>
warning C6551: Invalid size specification: expression not parsable
</description>
</rule>
<rule>
<key>C6552</key>
<configkey>C6552</configkey>
<priority>CRITICAL</priority>
<name>warning C6552: Invalid Deref= or Notref=: expression not parsable</name>
<description>
warning C6552: Invalid Deref= or Notref=: expression not parsable
</description>
</rule>
<rule>
<key>C6701</key>
<configkey>C6701</configkey>
<priority>CRITICAL</priority>
<name>warning C6701: The value is not a valid Yes/No/Maybe value: <string></name>
<description>
This warning is reported when there is an error in the annotations.
</description>
</rule>
<rule>
<key>C6702</key>
<configkey>C6702</configkey>
<priority>CRITICAL</priority>
<name>warning C6702: The value is not a string value: <string></name>
<description>
This warning is reported when there is an error in the annotations.
</description>
</rule>
<rule>
<key>C6703</key>
<configkey>C6703</configkey>
<priority>CRITICAL</priority>
<name>warning C6703: The value is not a number: <string></name>
<description>
This warning is reported when there is an error in the annotations.
</description>
</rule>
<rule>
<key>C6704</key>
<configkey>C6704</configkey>
<priority>CRITICAL</priority>
<name>warning C6704: Unexpected Annotation Expression Error: <annotation> [<why>]</name>
<description>
This warning is reported when there is an error in the annotations.
</description>
</rule>
<rule>
<key>C6705</key>
<configkey>C6705</configkey>
<priority>CRITICAL</priority>
<name>warning C6705: Annotation error expected <expected_number> arguments for annotation <parameter> found <actual_number>.</name>
<description>
This warning is reported when there is an error in the annotations.
</description>
</rule>
<rule>
<key>C6706</key>
<configkey>C6706</configkey>
<priority>CRITICAL</priority>
<name>warning C6706: Unexpected Annotation Error for annotation <annotation>: <why></name>
<description>
This warning is reported when there is an error in the annotations.
</description>
</rule>
<rule>
<key>C6707</key>
<configkey>C6707</configkey>
<priority>CRITICAL</priority>
<name>warning C6707: Unexpected Model Error: <why></name>
<description>
warning C6707: Unexpected Model Error: <why>
</description>
</rule>
<rule>
<key>C6995</key>
<configkey>C6995</configkey>
<priority>CRITICAL</priority>
<name>warning C6995: Failed to save XML Log file</name>
<description>
This warning indicates that the Code Analysis tool cannot create the defect log, which is the output of the code analysis.
This error might indicate a disk error or indicate that you do not have permission to create a file in the specified directory.
</description>
</rule>
<rule>
<key>C26100</key>
<configkey>C26100</configkey>
<priority>CRITICAL</priority>
<name>warning C26100: Race condition. Variable <var> should be protected by lock <lock>.</name>
<description>
The _Guarded_by_ annotation in the code specifies the lock to use to guard a shared variable. Warning C26100 is generated when the guard contract is violated.
</description>
</rule>
<rule>
<key>C26101</key>
<configkey>C26101</configkey>
<priority>CRITICAL</priority>
<name>warning C26101: Failing to use interlocked operation properly for variable <var>.</name>
<description>
Windows APIs offer a variety of interlocked operations. Annotation _Interlocked_ specifies that a variable should only be accessed through an interlocked operation. Warning C26101 is issued when an access is not consistent with the _Interlocked_ annotation.
</description>
</rule>
<rule>
<key>C26105</key>
<configkey>C26105</configkey>
<priority>CRITICAL</priority>
<name>warning C26105: Lock order violation. Acquiring lock <lock> with level <level> causes order inversion.</name>
<description>
Concurrency SAL supports lock levels. To declare a lock level, which is denoted by a string literal without double quotes, use _Create_lock_level_. You can impose an order of acquisition between two lock levels by using the annotation _Set_lock_level_order_(A,B), which states that locks that have level A must be acquired before locks that have level B. To establish a lock order hierarchy (a partial order among lock levels), use multiple _Set_lock_level_order_ annotations. To associate a lock with a lock level, use the _Set_lock_level_ annotation when you declare the lock. Warning C26105 is issued when a lock ordering violation is detected.
</description>
</rule>
<rule>
<key>C26110</key>
<configkey>C26110</configkey>
<priority>CRITICAL</priority>
<name>warning C26110: Caller failing to hold lock <lock> before calling function <func>.</name>
<description>
When a lock is required, make sure to clarify whether the function itself or its caller should acquire the lock. Warning C26110 is issued when there is a violation of the _Requires_lock_held_ annotation.
</description>
</rule>
<rule>
<key>C26111</key>
<configkey>C26111</configkey>
<priority>CRITICAL</priority>
<name>warning C26111: Caller failing to release lock <lock> before calling function <func>.</name>
<description>
The annotation _Requires_lock_not_held_ imposes a precondition that the lock count for the specified lock cannot be greater than zero when the function is called. Warning C26111 is issued when a function fails to release the lock before it calls another function.
</description>
</rule>
<rule>
<key>C26112</key>
<configkey>C26112</configkey>
<priority>CRITICAL</priority>
<name>warning C26112: Caller cannot hold any lock before calling <func>.</name>
<description>
The annotation _Requires_no_locks_held_ imposes a precondition that the caller must not hold any lock while it calls the function. Warning C26112 is issued when a function fails to release all locks before it calls another function.
</description>
</rule>
<rule>
<key>C26115</key>
<configkey>C26115</configkey>
<priority>CRITICAL</priority>
<name>warning C26115: Failing to release lock <lock> in function <func>.</name>
<description>
Enforcement of syntactically scoped lock acquire and lock release pairs in C/C++ programs is not performed by the language. A function may introduce a locking side effect by making an observable modification to the concurrency state. For example, a lock wrapper function increments the number of lock acquisitions, or lock count, for a given lock.
You can annotate a function that has a side effect from a lock acquire or lock release by using _Acquires_lock_ or _Releases_lock_, respectively. Without such annotations, a function is expected not to change any lock count after it returns. If acquires and releases are not balanced, they are considered to be orphaned. Warning C26115 is issued when a function introduces an orphaned lock.
</description>
</rule>
<rule>
<key>C26116</key>
<configkey>C26116</configkey>
<priority>CRITICAL</priority>
<name>warning C26116: Failing to acquire or to hold lock <lock> in <func>.</name>
<description>
Enforcement of syntactically scoped lock acquire and lock release pairs in C/C++ programs is not performed by the language. A function may introduce a locking side effect by making an observable modification to the concurrency state. For example, a lock wrapper function increments the number of lock acquisitions, or lock count, for a given lock.You can annotate a function that has a side effect from a lock acquire or lock release by using _Acquires_lock_ or _Requires_lock_held, respectively. Without such annotations, a function is expected not to change any lock count after it returns. If acquires and releases are not balanced, they are considered to be orphaned. Warning C26116 is issued when a function has been annotated with _Acquires_lock_, but it does not acquire a lock, or when a function is annotated with _Requires_lock_held and releases the lock.
</description>
</rule>
<rule>
<key>C26117</key>
<configkey>C26117</configkey>
<priority>CRITICAL</priority>
<name>warning C26117: Releasing unheld lock <lock> in function <func>.</name>
<description>
Enforcement of syntactically scoped lock acquire and lock release pairs in C/C++ programs is not performed by the language. A function may introduce a locking side effect by making an observable modification to the concurrency state. For example, a lock wrapper function increments the number of lock acquisitions, or lock count, for a given lock.You can annotate a function that has a side effect from a lock acquire or lock release by using _Acquires_lock_ or _Releases_lock_, respectively. Without such annotations, a function is expected not to change any lock count after it returns. If acquires and releases are not balanced, they are considered to be orphaned. Warning C26117 is issued when a function that has not been annotated with _Releases_lock_ releases a lock that it doesn't hold, because the function must own the lock before it releases it.
</description>
</rule>
<rule>
<key>C26130</key>
<configkey>C26130</configkey>
<priority>CRITICAL</priority>
<name>warning C26130: Missing annotation _Requires_lock_held_(<lock>) or _No_competing_thread_ at function <func>. Otherwise it could be a race condition.</name>
<description>
warning C26130: Missing annotation _Requires_lock_held_(<lock>) or _No_competing_thread_ at function <func>. Otherwise it could be a race condition. Variable <var> should be protected by lock <lock>.
Warning C26130 is issued when the analyzer detects a potential race condition but infers that the function is likely to be run in a single threaded mode, for example, when the function is in the initialization stage based on certain heuristics.
</description>
</rule>
<rule>
<key>C26135</key>
<configkey>C26135</configkey>
<priority>CRITICAL</priority>
<name>warning C26135: Missing annotation <annotation> at function <func>.</name>
<description>
Warning C26135 is issued when the analyzer infers that a function is a lock wrapper function that has a lock acquire or lock release side effect. If the code is not intended to be a wrapper function, then either the lock is leaking (if the lock is being acquired) or it is being released incorrectly (if the lock is being released).
</description>
</rule>
<rule>
<key>C26140</key>
<configkey>C26140</configkey>
<priority>CRITICAL</priority>
<name>warning C26140: Undefined lock kind <lock> in annotation <annotation> on lock <lock>.</name>
<description>
warning C26140: Undefined lock kind <lock> in annotation <annotation> on lock <lock>.
</description>
</rule>
<rule>
<key>C26160</key>
<configkey>C26160</configkey>
<priority>CRITICAL</priority>
<name>warning C26160: Caller possibly failing to hold lock <lock> before calling function <func>.</name>
<description>
Warning C26160 resembles warning C26110 except that the confidence level is lower. For example, the function may contain annotation errors.
</description>
</rule>
<rule>
<key>C26165</key>
<configkey>C26165</configkey>
<priority>CRITICAL</priority>
<name>warning C26165: Possibly failing to release lock <lock> in function <func>.</name>
<description>
Warning C26165 resembles warning C26115 except that the confidence level is lower. For example, the function may contain annotation errors.
</description>
</rule>
<rule>
<key>C26166</key>
<configkey>C26166</configkey>
<priority>CRITICAL</priority>
<name>warning C26166: Possibly failing to acquire or to hold lock <lock> in function <func>.</name>
<description>
Warning C26166 resembles warning C26116 except that the confidence level is lower. For example, the function may contain annotation errors.
</description>
</rule>
<rule>
<key>C26167</key>
<configkey>C26167</configkey>
<priority>CRITICAL</priority>
<name>warning C26167: Possibly releasing unheld lock <lock> in function <func>.</name>
<description>
Warning C26167 resembles warning C26117 except that the confidence level is lower. For example, the function may contain annotation errors.
</description>
</rule>
<rule>
<key>C28020</key>
<configkey>C28020</configkey>
<priority>CRITICAL</priority>
<name>warning C28020: The expression <expr> is not true at this call</name>
<description>
This warning is reported when the _Satisfies_ expression listed is not true. Frequently this indicates an incorrect parameter.
If this occurs on a function declaration, the annotations indicate an impossible condition.
</description>
</rule>
<rule>
<key>C28021</key>
<configkey>C28021</configkey>
<priority>CRITICAL</priority>
<name>warning C28021: The parameter <param> being annotated with <anno> must be a pointer</name>
<description>
This warning is reported when the object being annotated is not a pointer type. This annotation cannot be used with void or integral types.
</description>
</rule>
<rule>
<key>C28022</key>
<configkey>C28022</configkey>
<priority>CRITICAL</priority>
<name>warning C28022: The function class(es) <classlist1> on this function do not match the function class(es) <classlist2> on the typedef used to define it.</name>
<description>
This warning is reported when there is an error in the annotations. Both the typedef and the function itself have _Function_class_ annotations, but they do not match. If both are used they must match.
</description>
</rule>
<rule>
<key>C28023</key>
<configkey>C28023</configkey>
<priority>CRITICAL</priority>
<name>warning C28023: The function being assigned or passed should have a _Function_class_ annotation for at least one of the class(es) in: <classlist></name>
<description>
This warning is usually reported when only one function class is in use and a callback of the appropriate type is not declared.
This warning is issued when the function on the left side of the assignment (or of the implied assignment, if this is a function call) is annotated to indicate that it is a driver-specific function type that uses the _Function_class_ annotation or a typedef that contains such an annotation. The function on the right side of the assignment does not have a _Function_class_ annotation. The function on the right should be annotated to be of the same type as the function on the left. This is usually best done by adding the declaration <class1> <funcname1> before the current first declaration of <funcname2>.
</description>
</rule>
<rule>
<key>C28024</key>
<configkey>C28024</configkey>
<priority>CRITICAL</priority>
<name>warning C28024: The function pointer being assigned to is annotated with the function class <class>, which is not contained in the function class(es) <classlist>.</name>
<description>
This warning is reported when both functions were annotated with a function class, but the classes do not match.
This warning is issued when a function pointer has a _Function_class_ annotation that specifies that only functions of a particular functional class should be assigned to it. In an assignment or implied assignment in a function call, the source and target must be of the same function class, but the function classes do not match.
</description>
</rule>
<rule>
<key>C28039</key>
<configkey>C28039</configkey>
<priority>CRITICAL</priority>
<name>warning C28039: The type of actual parameter <operand> should exactly match the type <typename></name>
<description>
This warning is usually reported when an enum formal was not passed a member of the enum, but may also be used for other types.
Because C permits enums to be used interchangeably, and interchangeably with constants, it is easy to pass the wrong enum value to a function without an error.
For enum types, if the type of an enum parameter is annotated with _Enum_is_bitflag_, arithmetic is permitted on the parameter. Otherwise the parameter must be of exactly the correct type. If a constant is strictly required, warning C28137 may also apply.
This rule can be used for other parameter types as well; see the function documentation for why the types must match exactly.
</description>
</rule>
<rule>
<key>C28103</key>
<configkey>C28103</configkey>
<priority>CRITICAL</priority>
<name>warning C28103: Leaking resource</name>
<description>
The specified object contains a resource that has not been freed. A function being called has been annotated with __drv_acquiresResource or __drv_acquiresResourceGlobal and this warning indicates that the resource named in the annotation was not freed.
</description>
</rule>
<rule>
<key>C28104</key>
<configkey>C28104</configkey>
<priority>CRITICAL</priority>
<name>warning C28104: Resource that should have been acquired before function exit was not acquired</name>
<description>
A function that is intended to acquire a resource before it exits has exited without acquiring the resource. This warning indicates that the function is annotated with __drv_acquiresResource but does not return having actually acquired the resource. If this function is a wrapper function, a path through the function did not reach the wrapped function. If the failure to reach the wrapped function is because the function returned an error and did not actually acquire the resource, you might need to use a conditional annotation (__drv_when).
If this function actually implements the acquisition of the resource, it might not be possible for PFD to detect that the resource is acquired. In that case, use a #pragma warning to suppress the error. You can probably place the #pragma on the line preceding the { that begins the function body. The calling functions still need the annotation, but the Code Analysis tool will not be able to detect that the resource was acquired.
</description>
</rule>
<rule>
<key>C28105</key>
<configkey>C28105</configkey>
<priority>CRITICAL</priority>
<name>Warning C28105: Leaking resource due to an exception</name>
<description>
The specified resource is not freed when an exception is raised. The statement specified by the path can raise an exception. This warning is similar to warning C28103, except that in this case an exception is involved.
</description>
</rule>
<rule>
<key>C28106</key>
<configkey>C28106</configkey>
<priority>CRITICAL</priority>
<name>Warning C28106: Variable already holds resource possibly causing leak</name>
<description>
A variable that contains a resource is used in a context in which a new value can be placed in the variable. If this occurs, the resource can be lost and not properly freed, causing a resource leak.
</description>
</rule>
<rule>
<key>C28107</key>
<configkey>C28107</configkey>
<priority>CRITICAL</priority>
<name>warning C28107: Resource must be held when calling function</name>
<description>
A resource that the program must acquire before calling the function was not acquired when the function was called. As a result, the function call will fail. This warning is reported only when resources are acquired and released in the same function.
</description>
</rule>
<rule>
<key>C28108</key>
<configkey>C28108</configkey>
<priority>CRITICAL</priority>
<name>warning C28108: Variable holds an unexpected resource</name>
<description>
The resource that the driver is using is in the expected C language type, but has a different semantic type.
</description>
</rule>
<rule>
<key>C28109</key>
<configkey>C28109</configkey>
<priority>CRITICAL</priority>
<name>warning C28109: Variable cannot be held at the time function is called</name>
<description>
The program is holding a resource that should not be held when it is calling this function. Typically, it indicates that the resource was unintentionally acquired twice. The Code Analysis tool reports this warning when resources are acquired and released in the same function.
</description>
</rule>
<rule>
<key>C28112</key>
<configkey>C28112</configkey>
<priority>CRITICAL</priority>
<name>warning C28112: A variable which is accessed via an Interlocked function must always be accessed via an Interlocked function</name>
<description>
See line number: It is not always safe to access a variable which is accessed via the Interlocked* family of functions in any other way.
A variable that is accessed by using the Interlocked executive support routines, such as InterlockedCompareExchangeAcquire, is later accessed by using a different method.Although certain ordinary assignments, accesses, and comparisons to variables that are used by the Interlocked* routines can be safely accessed by using a different method, the risk is great enough to justify examining each instance.
</description>
</rule>
<rule>
<key>C28113</key>
<configkey>C28113</configkey>
<priority>CRITICAL</priority>
<name>warning C28113: Accessing a local variable via an Interlocked function</name>
<description>
The driver is using an Interlocked executive support routine, such as InterlockedDecrement, to access a local variable.
Although drivers are permitted to pass the address of a local variable to another function, and then use an interlocked function to operate on that variable, it's important to verify that the stack will not be swapped out to disk unexpectedly and that the variable has the correct life time across all threads that might use it.
</description>
</rule>
<rule>
<key>C28125</key>
<configkey>C28125</configkey>
<priority>CRITICAL</priority>
<name>warning C28125: The function must be called from within a try/except block</name>
<description>
The driver is calling a function that must be called from within a try/except block, such as ProbeForRead, ProbeForWrite, MmProbeAndLockPages.
</description>
</rule>
<rule>
<key>C28137</key>
<configkey>C28137</configkey>
<priority>CRITICAL</priority>
<name>warning C28137: The variable argument should instead be a (literal) constant</name>
<description>
This warning is reported when a function call is missing a required (literal) constant. Consult the documentation for the function.
</description>
</rule>
<rule>
<key>C28138</key>
<configkey>C28138</configkey>
<priority>CRITICAL</priority>
<name>warning C28138: The constant argument should instead be variable</name>
<description>
This warning is reported in a function call that expects a variable or a non-constant expression, but the call includes a constant. For information about the function and its parameter, consult the WDK documentation of the function.
</description>
</rule>
<rule>
<key>C28159</key>
<configkey>C28159</configkey>
<priority>CRITICAL</priority>
<name>warning C28159: Consider using another function instead.</name>
<description>
This warning is reported for Drivers is suggesting that you use a preferred function call that is semantically equivalent to the function that the driver is calling. This is a general warning message; the annotation __drv_preferredFunction was used (possibly with a conditional a __drv_when() annotation) to flag a bad coding practice.
</description>
</rule>
<rule>
<key>C28160</key>
<configkey>C28160</configkey>
<priority>CRITICAL</priority>
<name>warning C28160: Error annotation</name>
<description>
This warning is reported when a __drv_error annotation has been encountered. This annotation is used to flag coding practices that should be fixed, and can be used with a __drv_when annotation to indicate specific combinations of parameters.
</description>
</rule>
<rule>
<key>C28163</key>
<configkey>C28163</configkey>
<priority>CRITICAL</priority>
<name>warning C28163: The function should never be called from within a try/except block</name>
<description>
This warning is reported when a function is of a type that should never be enclosed in a try/except block is found in a try/except block. The code analysis tool found at least one path in which the function called was within a try/except block.
</description>
</rule>
<rule>
<key>C28164</key>
<configkey>C28164</configkey>
<priority>CRITICAL</priority>
<name>warning C28164: The argument is being passed to a function that expects a pointer to an object (not a pointer to a pointer)</name>
<description>
This warning is reported when a pointer to a pointer is used in a call to a function that is expecting a pointer to an object.
The function takes a PVOID in this position. Usually, this indicates that &pXXX was used when pXXX is required.
Some polymorphic functions (functions that can evaluate to, and be applied to, values of different types) are implemented in C by using a PVOID argument that takes any pointer type. However, this allows the programmer to code a pointer to a pointer without causing a compiler error, even when this type is not appropriate.
</description>
</rule>
<rule>
<key>C28182</key>
<configkey>C28182</configkey>
<priority>CRITICAL</priority>
<name>warning C28182: Dereferencing NULL pointer.</name>
<description>
Additional information: <pointer1> contains the same NULL value as <pointer2> did <note>
The code analysis tool reports this warning when it confirms that the pointer can be NULL. If there are unconfirmed instances where the error might occur earlier in the trace, the code analysis tool adds the line number of the first instance to the warning message so that you can change the code to address all instances.
<pointer2> is confirmed to be potentially NULL. <pointer1> contains the same value as pointer2 and is being dereferenced. Because these pointers may be at very different places in the code, both are reported so that you can determine why the code analysis tool is reporting this warning.
If an unconfirmed earlier instance of the condition exists, then <note> is replaced by this text: "See line <number> for an earlier location where this can occur."
</description>
</rule>
<rule>
<key>C28183</key>
<configkey>C28183</configkey>
<priority>CRITICAL</priority>
<name>warning C28183: The argument could be one value, and is a copy of the value found in the pointer</name>
<description>
This warning indicates that this value is unexpected in the current context. This warning usually appears when a NULL value is passed as an argument to a function that does not permit it. The value was actually found in the specified variable, and the argument is a copy of that variable.
The Code Analysis tool reports this warning at the first point where it can definitively determine that the pointer is NULL or that it contains an illegal value. However, it is often the case that the error could actually occur earlier in the trace. When this happens, the Code Analysis tool will also give the line number of the first possible instance -- usually at a location where it could not definitively determine that the warning was appropriate. In those cases, the earlier location where this can occur is appended to the warning message. Typically, a code change should occur at or before that line number, rather than at the point of report.
</description>
</rule>
<rule>
<key>C28193</key>
<configkey>C28193</configkey>
<priority>CRITICAL</priority>
<name>warning C28193: The variable holds a value that must be examined</name>
<description>
This warning indicates that the calling function is not checking the value of the specified variable, which was supplied by a function. The returned value is annotated with the _Check_return_ annotation, but the calling function is either not using the value or is overwriting the value without examining it.
This warning is similar to warning C6031, but it is reported only when the code does not test or examine the value of the variable, such as by using it in a comparison. Simply assigning the value is not considered to be a sufficient examination to avoid this warning. Aliasing the result out of the function is considered a sufficient examination, but the result itself should be annotated with _Check_return_.
Certain functions (such as strlen) exist almost exclusively for their return value, so it makes sense for them to have the _Check_return_ annotation. For these functions, the Code Analysis tool might report this warning when the return value is unused. This usually indicates that the code is incorrect, for example, it might contain residual code that could be deleted. However, in some rare instances, the return value is intentionally not used. The most common of these instances is where a string length is returned but not actually used before some other test is made. That other test causes a path to be simulated where the string length ends up being unused. When this happens, the code can be correct, but it might be inefficient.
There are two primary strategies for dealing with these cases where the return value is unused:
Reorder the code so that the string length is only returned along the path where it is needed.
Use a #pragma warning to suppress the warning--if by reordering the code, you would make the code too complex or otherwise less useful.
</description>
</rule>
<rule>
<key>C28194</key>
<configkey>C28194</configkey>
<priority>CRITICAL</priority>
<name>warning C28194: The function was declared as aliasing the value in variable and exited without doing so</name>
<description>
This warning indicates that the function prototype for the function being analyzed has a __drv_isAliased annotation, which indicates that it will alias the specified argument (that is, assign the value in a way that it will survive returning from the function). However, the function does not alias the argument along the path that is indicated by the annotation. Most functions that alias a variable save its value to a global data structure.
</description>
</rule>
<rule>
<key>C28195</key>
<configkey>C28195</configkey>
<priority>CRITICAL</priority>
<name>warning C28195: The function was declared as acquiring memory in a variable and exited without doing so</name>
<description>
This warning indicates that the function prototype for the function being analyzed has a __drv_acquiresMemory annotation. The __drv_acquiresMemory annotation indicates that the function acquires memory in the designated result location, but in at least one path, the function did not acquire the memory. Note that the Code Analysis tool will not recognize the actual implementation of a memory allocator (involving address arithmetic) and will not recognize that memory is allocated (although many wrappers will be recognized). In this case, the Code Analysis tool does not recognize that the memory was allocated and issues this warning. To suppress the false positive, use a #pragma warning on the line that precedes the opening brace { of the function body
</description>
</rule>
<rule>
<key>C28196</key>
<configkey>C28196</configkey>
<priority>CRITICAL</priority>
<name>warning C28196: The requirement is not satisfied. (The expression does not evaluate to true.)</name>
<description>
This warning indicates that the function prototype for the function being analyzed has a __notnull, __null or __drv_valueIs on an _Out_ parameter or the return value, but the value returned is inconsistent with that annotation.
</description>
</rule>
<rule>
<key>C28197</key>
<configkey>C28197</configkey>
<priority>CRITICAL</priority>
<name>Warning C28197: Possibly leaking memory</name>
<description>
This warning is reported for both memory and resource leaks when the resource is potentially aliased to another location.
The pointer points to allocated memory or to another allocated resource that was not explicitly freed. This warning is usually due to inadequate annotations on the called function, although inadequate annotations on the calling function can also make this more likely.
This warning can be reported on function exit if an input argument has a __drv_freesMem or __drv_aliasesMem annotation. This warning typically indicates either a valid leak or that a function called by the current function needs additional annotation.
In particular, the absence of the basic _In_ and _Out_ annotations make this warning fairly likely, although the __drv_aliasesMem and __drv_freesMem annotations might be needed as well. A false positive is a likely result of a missing _In_ annotation.
Functions that take a pointer and alias it (thus avoiding a leak) should be annotated with __drv_aliasesMem. If you create a function that inserts an object into a global structure, or passes it to a system function that does that, you should add the __drv_aliasesMem annotation.
Functions that free memory should be annotated with __drv_freesMem. The major functions that free memory already have this annotation.
</description>
</rule>
<rule>
<key>C28198</key>
<configkey>C28198</configkey>
<priority>CRITICAL</priority>
<name>warning C28198: Possibly leaking memory due to an exception.</name>
<description>
This warning indicates that allocated memory is not being freed after an exception is raised. The statement at the end of the path can raise an exception. The memory was passed to a function that might have saved a copy to be freed later.
This warning is very similar to warning C28197. The annotations that are recommended for use with warning C28197 can also be used here.
</description>
</rule>
<rule>
<key>C28199</key>
<configkey>C28199</configkey>
<priority>CRITICAL</priority>
<name>warning C28199: Using possibly uninitialized memory</name>
<description>
This message indicates that the variable has had its address taken but no assignment to it has been discovered.
The specified variable is being used without being explicitly initialized, but at some point its address was taken, indicating that it might be initialized invisibly to the Code Analysis tool.
This warning can be mistaken if the variable is initialized outside of the function.
The Code Analysis tool reports this warning on function exit if a parameter has an _Out_ or _Inout_ annotation and the variable is not initialized.
</description>
</rule>
<rule>
<key>C28202</key>
<configkey>C28202</configkey>
<priority>CRITICAL</priority>
<name>warning C28202: Illegal reference to non-static member</name>
<description>
This warning is reported when there is an error in the annotations.
</description>
</rule>
<rule>
<key>C28203</key>
<configkey>C28203</configkey>
<priority>CRITICAL</priority>
<name>warning C28203: Ambiguous reference to class member. Could be <name1> or <name2></name>
<description>
This warning is reported when there is an error in the annotations.
</description>
</rule>
<rule>
<key>C28204</key>
<configkey>C28204</configkey>
<priority>CRITICAL</priority>
<name>warning C28204: <function> : Only one of this overload and the one at <filename>(<line>) are annotated for <paramname>: both or neither must be annotated.</name>
<description>
This warning is reported when there is an error in the annotations.
</description>
</rule>
<rule>
<key>C28205</key>
<configkey>C28205</configkey>
<priority>CRITICAL</priority>
<name>warning C28205: function> : _Success_ or _On_failure_ used in an illegal context: <why></name>
<description>
This warning is reported when there is an error in the annotations.
</description>
</rule>
<rule>
<key>C28206</key>
<configkey>C28206</configkey>
<priority>CRITICAL</priority>
<name>warning C28206: <expression> : left operand points to a struct, use -></name>
<description>
This warning is reported when the struct pointer dereference notation -> was expected.
</description>
</rule>
<rule>
<key>C28207</key>
<configkey>C28207</configkey>
<priority>CRITICAL</priority>
<name>warning C28207: <expression>: left operand is a struct, use .</name>
<description>
This warning is reported when a struct dereference dot (.) was expected.
</description>
</rule>
<rule>
<key>C28208</key>
<configkey>C28208</configkey>
<priority>CRITICAL</priority>
<name>warning C28208: Function <function> was previously defined with a different parameter list at <file>(<line>). Some analysis tools will yield incorrect results</name>
<description>
This warning is reported when a function’s known definition doesn’t match another occurrence.
</description>
</rule>
<rule>
<key>C28209</key>
<configkey>C28209</configkey>
<priority>CRITICAL</priority>
<name>warning C28209: The declaration for symbol has a conflicting declaration</name>
<description>
This warning indicates an incorrectly constructed annotation declaration. This warning should never occur in normal use.
</description>
</rule>
<rule>
<key>C28210</key>
<configkey>C28210</configkey>
<priority>CRITICAL</priority>
<name>warning C28210: Annotations for the _On_failure_ context must not be in explicit pre context</name>
<description>
Annotations _On_failure_ must be explicitly or implicitly indicated in __post context, that is, to be applied after the function returns. Use _drv_out to ensure this.
</description>
</rule>
<rule>
<key>C28211</key>
<configkey>C28211</configkey>
<priority>CRITICAL</priority>
<name>warning C28211: Static context name expected for SAL_context</name>
<description>
This warning indicates that the operand to the _Static_context_ annotation must be the name of a tool-defined context. This warning should never occur in normal use.
</description>
</rule>
<rule>
<key>C28212</key>
<configkey>C28212</configkey>
<priority>CRITICAL</priority>
<name>warning C28212: Pointer expression expected for annotation</name>
<description>
This warning indicates that the numbered parameter to an annotation (not the function being annotated) is expected to be a pointer or array type, but some other type was encountered. The annotation needs to be corrected.
</description>
</rule>
<rule>
<key>C28213</key>
<configkey>C28213</configkey>
<priority>CRITICAL</priority>
<name>warning C28213: The _Use_decl_annotations_ annotation must be used to reference, without modification, a prior declaration. <why></name>
<description>
This warning is reported when a prior declaration is referenced without the required _Use_decl_annotations_ annotation.
</description>
</rule>
<rule>
<key>C28214</key>
<configkey>C28214</configkey>
<priority>CRITICAL</priority>
<name>warning C28214: Attribute parameter names must be p1...p9</name>
<description>
This warning indicates that when you construct an annotation declaration, the parameter names are limited to p1...p9. This warning should never occur in normal use.
</description>
</rule>
<rule>
<key>C28215</key>
<configkey>C28215</configkey>
<priority>CRITICAL</priority>
<name>warning C28215: The typefix cannot be applied to a parameter that already has a typefix</name>
<description>
Applying a __typefix annotation to a parameter that already has that annotation is an error. The __typefix annotations are used only in a few special cases and this warning is not expected to be seen in normal use.
</description>
</rule>
<rule>
<key>C28216</key>
<configkey>C28216</configkey>
<priority>CRITICAL</priority>
<name>warning C28216: The _Check_return_ annotation only applies to post-conditions for the specific function parameter.</name>
<description>
The _Check_return_ annotation has been applied in a context other than __post; it may need a __post (or __drv_out) modifier, or it may be placed incorrectly.
</description>
</rule>
<rule>
<key>C28217</key>
<configkey>C28217</configkey>
<priority>CRITICAL</priority>
<name>warning C28217: For function, the number of parameters to annotation does not match that found at file</name>
<description>
The annotations on the current line and on the line in the message are inconsistent. This should not be possible if the standard macros are being used for annotations; this warning is not expected to be seen in normal use.
</description>
</rule>
<rule>
<key>C28218</key>
<configkey>C28218</configkey>
<priority>CRITICAL</priority>
<name>warning C28218: For function parameter, the annotation's parameter does not match that found at file</name>
<description>
The annotations on the current line and on the line in the message are inconsistent. This should not be possible if the standard macros are being used for annotations; this warning is not expected to be seen in normal use.
</description>
</rule>
<rule>
<key>C28219</key>
<configkey>C28219</configkey>
<priority>CRITICAL</priority>
<name>warning C28219: Member of enumeration expected for annotation the parameter in the annotation</name>
<description>
A parameter to an annotation is expected to be a member of the named enum type, and some other symbol was encountered; use a member of that enum type. This usually indicates an incorrectly coded annotation macro.
</description>
</rule>
<rule>
<key>C28220</key>
<configkey>C28220</configkey>
<priority>CRITICAL</priority>
<name>warning C28220: Integer expression expected for annotation the parameter in the annotation</name>
<description>
This warning indicates that a parameter to an annotation is expected to be an integer expression, and some other type was encountered. This usually indicates an incorrectly coded annotation macro.
</description>
</rule>
<rule>
<key>C28221</key>
<configkey>C28221</configkey>
<priority>CRITICAL</priority>
<name>warning C28221: String expression expected for the parameter in the annotation</name>
<description>
This warning indicates that a parameter to an annotation is expected to be a string, and some other type was encountered. This usually indicates an incorrectly coded annotation macro and is not expected to be seen in normal use.
</description>
</rule>
<rule>
<key>C28222</key>
<configkey>C28222</configkey>
<priority>CRITICAL</priority>
<name>warning C28222: _Yes_, _No_, or _Maybe_ expected for annotation</name>
<description>
This warning indicates that a parameter to an annotation is expected to be one of the symbols _Yes_, _No_, or _Maybe_, and some other symbol was encountered. This usually indicates an incorrectly coded annotation macro.
</description>
</rule>
<rule>
<key>C28223</key>
<configkey>C28223</configkey>
<priority>CRITICAL</priority>
<name>Warning C28223: Did not find expected Token/identifier for annotation, parameter</name>
<description>
This warning indicates that a parameter to an annotation is expected to be an identifier, and some other symbol was encountered. This usually indicates an incorrectly coded annotation macro. The use of C or C++ keywords in this position will cause this error.
</description>
</rule>
<rule>
<key>C28224</key>
<configkey>C28224</configkey>
<priority>CRITICAL</priority>
<name>warning C28224: Annotation requires parameters</name>
<description>
This warning indicates that the named annotation is used without parameters and at least one parameter is required. This should not be possible if the standard macros are being used for annotations; this warning is not expected to be seen in normal use.
</description>
</rule>
<rule>
<key>C28225</key>
<configkey>C28225</configkey>
<priority>CRITICAL</priority>
<name>warning C28225: Did not find the correct number of required parameters in annotation</name>
<description>
This warning indicates that the named annotation is used with the incorrect number of parameters. This should not be possible if the standard macros are being used for annotations; this warning is not expected to be seen in typical use.
</description>
</rule>
<rule>
<key>C28226</key>
<configkey>C28226</configkey>
<priority>CRITICAL</priority>
<name>Warning C28226: Annotation cannot also be a PrimOp (in current declaration)</name>
<description>
This warning indicates that the named annotation is being declared as a PrimOp, and also was previously declared as a normal annotation. This should not be possible if the standard macros are being used for annotations; this warning is not expected to be seen in normal use.
</description>
</rule>
<rule>
<key>C28227</key>
<configkey>C28227</configkey>
<priority>CRITICAL</priority>
<name>Warning C28227: Annotation cannot also be a PrimOp (see prior declaration)</name>
<description>
This warning indicates that the named annotation is being declared as an ordinary annotation, and also was previously declared as a PrimOp. This should not be possible if the standard macros are being used for annotations; this warning is not expected to be seen in typical use.
</description>
</rule>
<rule>
<key>C28228</key>
<configkey>C28228</configkey>
<priority>CRITICAL</priority>
<name>warning C28228: Annotation parameter: cannot use type in annotations</name>
<description>
This warning indicates that a parameter is of type that is not supported. Annotations can only use a limited set of types as parameters. This should not be possible if the standard macros are being used for annotations; this warning is not expected to be seen in typical use.
</description>
</rule>
<rule>
<key>C28229</key>
<configkey>C28229</configkey>
<priority>CRITICAL</priority>
<name>warning C28229: Annotation does not support parameters</name>
<description>
This warning indicates that an annotation was used with a parameter when the annotation is declared without parameters. This should not be possible if the standard macros are being used for annotations; this warning is not expected to be seen in typical use.
</description>
</rule>
<rule>
<key>C28230</key>
<configkey>C28230</configkey>
<priority>CRITICAL</priority>
<name>warning C28230: The type of parameter has no member.</name>
<description>
This warning indicates that an argument to an annotation attempts to access a struct, class, or union and the named member does not exist.
</description>
</rule>
<rule>
<key>C28231</key>
<configkey>C28231</configkey>
<priority>CRITICAL</priority>
<name>warning C28231: Annotation is only valid on array</name>
<description>
This warning indicates that an argument to an annotation should be an array, and some other type was encountered.
</description>
</rule>
<rule>
<key>C28232</key>
<configkey>C28232</configkey>
<priority>CRITICAL</priority>
<name>warning C28232: _Pre_, _Post_, or _Deref_ not applied to any annotation</name>
<description>
This warning indicates that a _Pre_, _Post_, or _Deref_ operator appears in an annotation expression without a subsequent functional annotation; the modifier was ignored, but this indicates an incorrectly coded annotation.
</description>
</rule>
<rule>
<key>C28233</key>
<configkey>C28233</configkey>
<priority>CRITICAL</priority>
<name>warning C28233: pre, post, or deref applied to a block</name>
<description>
warning C28233: pre, post, or deref applied to a block
</description>
</rule>
<rule>
<key>C28234</key>
<configkey>C28234</configkey>
<priority>CRITICAL</priority>
<name>warning C28234: _At_ expression does not apply to current function</name>
<description>
This warning indicates that the value of an _At_ expression does not identify an accessible object.
</description>
</rule>
<rule>
<key>C28235</key>
<configkey>C28235</configkey>
<priority>CRITICAL</priority>
<name>warning C28235: The function cannot stand alone as an annotation</name>
<description>
This warning indicates that an attempt was made to use a function that was not declared to be an annotation in an annotation context. This includes using a primitive operation (PrimOp) in a standalone context. This should not be possible if the standard macros are being used for annotations. This warning is not expected to be seen in typical use.
</description>
</rule>
<rule>
<key>C28236</key>
<configkey>C28236</configkey>
<priority>CRITICAL</priority>
<name>warning C28236: The annotation cannot be used in an expression</name>
<description>
This warning indicates that an attempt was made to use a function declared to be an annotation in an expression context. This should not be possible if the standard macros are being used for annotations; this warning is not expected to be seen in typical use.
</description>
</rule>
<rule>
<key>C28237</key>
<configkey>C28237</configkey>
<priority>CRITICAL</priority>
<name>warning C28237: The annotation on parameter is no longer supported</name>
<description>
An internal error has occurred in the PREfast model file. This warning should not occur in typical use.
</description>
</rule>
<rule>
<key>C28238</key>
<configkey>C28238</configkey>
<priority>CRITICAL</priority>
<name>warning C28238: The annotation on parameter has more than one of value, stringValue, and longValue. Use paramn=xxx</name>
<description>
An internal error has occurred in the PREfast model file. This warning should not occur in typical use.
</description>
</rule>
<rule>
<key>C28239</key>
<configkey>C28239</configkey>
<priority>CRITICAL</priority>
<name>warning C28239: The annotation on parameter has both value, stringValue, or longValue; and paramn=xxx. Use only paramn=xxx</name>
<description>
An internal error has occurred in the PREfast model file. This warning should not occur in typical use.
</description>
</rule>
<rule>
<key>C28240</key>
<configkey>C28240</configkey>
<priority>CRITICAL</priority>
<name>warning C28240: The annotation on parameter has param2 but no param1</name>
<description>
An internal error has occurred in the PREfast model file. This warning should not occur in typical use.
</description>
</rule>
<rule>
<key>C28241</key>
<configkey>C28241</configkey>
<priority>CRITICAL</priority>
<name>warning C28241: The annotation for function on parameter is not recognized</name>
<description>
An unrecognized annotation name was used. This should not be possible if the standard macros are being used for annotations; this warning is not expected to be seen in typical use.
</description>
</rule>
<rule>
<key>C28243</key>
<configkey>C28243</configkey>
<priority>CRITICAL</priority>
<name>warning C28243: The annotation for function on parameter requires more dereferences than the actual type annotated allows</name>
<description>
The number of __deref operators on an annotation is more than the number of levels of pointer defined by the parameter type. Correct this warning by changing either the number in the annotation or the pointer levels of the parameter referenced.
</description>
</rule>
<rule>
<key>C28244</key>
<configkey>C28244</configkey>
<priority>CRITICAL</priority>
<name>warning C28244: The annotation for function has an unparseable parameter/external annotation</name>
<description>
This should currently not be possible if the standard macros are being used for annotations; this warning is not expected to be seen in typical use.
</description>
</rule>
<rule>
<key>C28245</key>
<configkey>C28245</configkey>
<priority>CRITICAL</priority>
<name>warning C28245: The annotation for function annotates 'this' on a non-member-function</name>
<description>
An internal error has occurred in the PREfast model file. This warning should not occur in typical use.
</description>
</rule>
<rule>
<key>C28246</key>
<configkey>C28246</configkey>
<priority>CRITICAL</priority>
<name>warning C28246: The annotation for function '<name>' - parameter '<parameter>' does not match the type of the parameter</name>
<description>
A __deref operator was applied to a non-pointer type when creating an annotation.
</description>
</rule>
<rule>
<key>C28250</key>
<configkey>C28250</configkey>
<priority>CRITICAL</priority>
<name>warning C28250: Inconsistent annotation for function: the prior instance has an error.</name>
<description>
Note: There are several prototypes for this function. This warning compares the first prototype with instance number <number>.
If a declaration is made using a typedef, the line where the typedef appears is more useful than the line of the declaration.
This warning refers to an error in the annotation and reflects the requirement that the annotations on a function declaration must match those on the definition, except if a function typedef is involved. In that case, the function typedef is taken as definitive for both the declaration and the definition.
Note that annotations are usually implemented as macros, and one macro will usually yield several low-level annotations. This warning is reported for each unmatched low-level annotation, so a single unmatched annotation macro may yield a number of unmatched low-level annotations. It is best to simply compare the declaration and definition source code to make sure that they are the same. (Trivial differences in the order of the annotations are not reported.)
The comparison is always between the first declaration found and the current one. If there are additional declarations, each declaration is checked pairwise. It is currently not possible to do a comparison other than in pairs, although it is possible to identify that there are more than two declarations/definitions. The text field above contains a list of the annotations that differ (at a fairly low level) between the two instances.
This warning message displays the text of the underlying code sent to the compiler, and not the macros that are used to actually insert the annotation in the source code (as is the case whenever macros are used). In general, you do not need to understand the low-level annotations, but you should recognize that the annotations are being reported as inconsistent between the line numbers reported in the error message. Mostly, an inspection of the source code will make it clear why the inconsistency exists.
</description>
</rule>
<rule>
<key>C28251</key>
<configkey>C28251</configkey>
<priority>CRITICAL</priority>
<name>warning C28251: Inconsistent annotation for function: this instance has an error</name>
<description>
This warning refers to an error in the annotation and reflects the requirement that the annotations on a function declaration must match those on the definition, except if a function typedef is involved. In that case, the function typedef is taken as definitive for both the declaration and the definition.
Note that annotations are usually implemented as macros, and one macro will usually yield several low-level annotations. This warning is reported for each unmatched low-level annotation, so a single unmatched annotation macro may yield a number of unmatched low-level annotations. It is best to simply compare the declaration and definition source code to make sure that they are the same. (Trivial differences in the order of the annotations are not reported.)
The comparison is always between the first declaration found and the current one. If there are additional declarations, then each declaration is checked in groups of two. It is currently not possible to do a comparison other than in pairs, although it is possible to identify that there are more than two declarations/definitions. The text field above contains a list of the annotations that differ (at a fairly low level) between the two instances.
This warning message displays the text of the underlying code sent to the compiler, and not the macros that are used to actually insert the annotation in the source code (as is the case whenever macros are used). In general, you do not need to understand the low-level annotations, but you should recognize that the annotations are being reported as inconsistent between the line numbers reported in the error message. Mostly, an inspection of the source code will make it clear why the inconsistency exists.
</description>
</rule>
<rule>
<key>C28252</key>
<configkey>C28252</configkey>
<priority>CRITICAL</priority>
<name>warning C28252: Inconsistent annotation for function: parameter has another annotation on this instance</name>
<description>
This warning refers to an error in the annotation and reflects the requirement that the annotations on a function declaration must match those on the definition, except if a function typedef is involved. In that case, the function typedef is taken as definitive for both the declaration and the definition.
Note that annotations are usually implemented as macros, and one macro will usually yield several low-level annotations. This warning is reported for each unmatched low-level annotation, so a single unmatched annotation macro may yield a number of unmatched low-level annotations. It is best to simply compare the declaration and definition source code to make sure that they are the same. (Trivial differences in the order of the annotations are not reported.)
The comparison is always between the first declaration found and the current one. If there are additional declarations, then each declaration is checked in groups of two. It is currently not possible to do a comparison other than in pairs, although it is possible to identify that there are more than two declarations/definitions. The error message contains a list of the annotations that differ (at a fairly low level) between the two instances.
This warning message displays the text of the underlying code sent to the compiler, and not the macros that are used to actually insert the annotation in the source code (as is the case whenever macros are used). In general, you do not need to understand the low-level annotations, but you should recognize that the annotations are being reported as inconsistent between the line numbers reported in the error message. Mostly, an inspection of the source code will make it clear why the inconsistency exists.
</description>
</rule>
<rule>
<key>C28253</key>
<configkey>C28253</configkey>
<priority>CRITICAL</priority>
<name>warning C28253: Inconsistent annotation for function: parameter has another annotations on this instance</name>
<description>
This warning refers to an error in the annotation and reflects the requirement that the annotations on a function declaration must match those on the definition, except if a function typedef is involved. In that case, the function typedef is taken as definitive for both the declaration and the definition.
Note that annotations are usually implemented as macros, and one macro will usually yield several low-level annotations. This warning is reported for each unmatched low-level annotation, so a single unmatched annotation macro may yield a number of unmatched low-level annotations. It is best to simply compare the declaration and definition source code to make sure that they are the same. (Trivial differences in the order of the annotations are not reported.)
The comparison is always between the first declaration found and the current one. If there are additional declarations, then each declaration is checked in groups of two. It is currently not possible to do a comparison other than in pairs, although it is possible to identify that there are more than two declarations/definitions. The error message contains a list of the annotations that differ (at a fairly low level) between the two instances.
This warning message displays the text of the underlying code sent to the compiler, and not the macros that are used to actually insert the annotation in the source code (as is the case whenever macros are used). In general, you do not need to understand the low-level annotations, but you should recognize that the annotations are being reported as inconsistent between the line numbers reported in the error message. Mostly, an inspection of the source code will make it clear why the inconsistency exists.
</description>
</rule>
<rule>
<key>C28254</key>
<configkey>C28254</configkey>
<priority>CRITICAL</priority>
<name>warning C28254: dynamic_cast<>() is not supported in annotations</name>
<description>
The C++ dynamic_cast operator cannot be used in annotations.
</description>
</rule>
<rule>
<key>C28262</key>
<configkey>C28262</configkey>
<priority>CRITICAL</priority>
<name>warning C28262: A syntax error in the annotation was found in function <function> for annotation <name></name>
<description>
warning C28262: A syntax error in the annotation was found in function <function> for annotation <name>
</description>
</rule>
<rule>
<key>C28263</key>
<configkey>C28263</configkey>
<priority>CRITICAL</priority>
<name>warning C28263: A syntax error in a conditional annotation was found for Intrinsic annotation</name>
<description>
The Code Analysis tool reports this warning when the return value for the specified function has a conditional value. This warning indicates an error in the annotations, not in the code being analyzed. If the function declaration is in a header file, the annotation should be corrected so that it matches the header file.
The result list for the function and parameter specified has multiple unconditional values.
Typically, this indicates that more than one unconditional _Null_ or __drv_valueIs annotations have been used to specify a result value.
</description>
</rule>
<rule>
<key>C28267</key>
<configkey>C28267</configkey>
<priority>CRITICAL</priority>
<name>warning C28267: A syntax error in the annotations was found annotation <name> in the function <function>.</name>
<description>
warning C28267: A syntax error in the annotations was found annotation <name> in the function <function>.
</description>
</rule>
<rule>
<key>C28272</key>
<configkey>C28272</configkey>
<priority>CRITICAL</priority>
<name>warning C28272: The annotation for function, parameter when examining is inconsistent with the function declaration</name>
<description>
This warning indicates an error in the annotations, not in the code that is being analyzed. The annotations appearing on a function definition are inconsistent with those appearing on a declaration. The two annotations should be resolved to match.
</description>
</rule>
<rule>
<key>C28273</key>
<configkey>C28273</configkey>
<priority>CRITICAL</priority>
<name>warning C28273: For function, the clues are inconsistent with the function declaration</name>
<description>
This warning indicates an error in the annotations, not in the code that is being analyzed. The annotations appearing on a function definition are inconsistent with those appearing on a declaration. The two annotations should be resolved to match.
</description>
</rule>
<rule>
<key>C28275</key>
<configkey>C28275</configkey>
<priority>CRITICAL</priority>
<name>warning C28275: The parameter to _Macro_value_ is null</name>
<description>
This warning indicates that there is an internal error in the model file, not in the code being analyzed. The macroValue function was called without a parameter.
</description>
</rule>
<rule>
<key>C28278</key>
<configkey>C28278</configkey>
<priority>CRITICAL</priority>
<name>Warning C28278: Function name appears with no prototype in scope.</name>
<description>
This warning typically indicates that a __deref is needed to apply the __return annotation to the value returned.
The Code Analysis tool reports this warning when a function without a declaration was called, and the analysis that can be performed is limited because the declaration contains important information.
The C language permits (but discourages) the use of a function for which no prototype has been declared. A function definition or a function declaration (prototype) should appear before the first use of the function. This warning indicates that a function without a declaration was called, and the analysis that can be performed is limited because declaration contains important information. If the function declaration were to contain annotations, the function declaration is even more useful to the Code Analysis tool.
</description>
</rule>
<rule>
<key>C28279</key>
<configkey>C28279</configkey>
<priority>CRITICAL</priority>
<name>warning C28279: For symbol, a 'begin' was found without a matching 'end'</name>
<description>
The annotation language supports a begin and end ({ and } in C) construct, and the pairing has gotten unbalanced. This situation can be avoided if the macros are used.
</description>
</rule>
<rule>
<key>C28280</key>
<configkey>C28280</configkey>
<priority>CRITICAL</priority>
<name>warning C28280: For symbol, an 'end' was found without a matching 'begin'</name>
<description>
The annotation language supports a begin and an end ({ and } in C) construct, and the pairing has gotten unbalanced. This situation can be avoided if the macros are used.
</description>
</rule>
<rule>
<key>C28282</key>
<configkey>C28282</configkey>
<priority>CRITICAL</priority>
<name>warning C28282: Format Strings must be in preconditions</name>
<description>
This warning indicates that a __drv_formatString annotation is found, which is not in a _Pre_ (__drv_in) annotation (function parameters are by default _Pre_). Check whether the annotation used in an explicit block with a _Post_ (__drv_out) annotation. If so, remove the annotation from any enclosing block that has put it in a _Post_ context.
</description>
</rule>
<rule>
<key>C28283</key>
<configkey>C28283</configkey>
<priority>CRITICAL</priority>
<name>warning C28283: For symbol, the specified size specification is not yet supported</name>
<description>
The warning indicates that the size specification "sentinel" annotation received a value other than zero. Essentially, the caller tried to say that the string is terminated by a character other than binary zero.
</description>
</rule>
<rule>
<key>C28284</key>
<configkey>C28284</configkey>
<priority>CRITICAL</priority>
<name>warning C28284: For symbol, Predicates are currently not supported for non-function symbols</name>
<description>
This warning indicates that a conditional annotation (predicate, __drv_when) was found on something other than a function.
</description>
</rule>
<rule>
<key>C28285</key>
<configkey>C28285</configkey>
<priority>CRITICAL</priority>
<name>warning C28285: For function, syntax error in parameter</name>
<description>
The Code Analysis tool reports this warning when a probable error is encountered in the model file. A few source file errors can also cause such errors.
</description>
</rule>
<rule>
<key>C28286</key>
<configkey>C28286</configkey>
<priority>CRITICAL</priority>
<name>warning C28286: For function, syntax error near the end</name>
<description>
The Code Analysis tool reports this warning when a probable error is encountered in the model file. A few source file errors can also cause such errors.
</description>
</rule>
<rule>
<key>C28287</key>
<configkey>C28287</configkey>
<priority>CRITICAL</priority>
<name>warning C28287: For function, syntax Error in _At_() annotation (unrecognized parameter name)</name>
<description>
The Code Analysis tool reports this warning when the SAL_at (__drv_at) annotation is used and the parameter expression cannot be interpreted in the current context. This might include using a misspelled parameter or member name, or a misspelling of "return" or "this" keywords.
</description>
</rule>
<rule>
<key>C28288</key>
<configkey>C28288</configkey>
<priority>CRITICAL</priority>
<name>warning C28288: For function, syntax Error in _At_() annotation (invalid parameter name)</name>
<description>
The Code Analysis tool reports this warning when the SAL_at (__drv_at) annotation is used and the parameter expression cannot be interpreted in the current context. This might include using a misspelled parameter or member name, or a misspelling of "return" or "this" keywords.
</description>
</rule>
<rule>
<key>C28289</key>
<configkey>C28289</configkey>
<priority>CRITICAL</priority>
<name>warning C28289: For function: ReadableTo or WritableTo did not have a limit-spec as a parameter</name>
<description>
The Code Analysis tool reports this warning when the function/parameter annotation is miscoded as noted.
</description>
</rule>
<rule>
<key>C28290</key>
<configkey>C28290</configkey>
<priority>CRITICAL</priority>
<name>warning C28290: the annotation for function contains more Externals than the actual number of parameters</name>
<description>
The Code Analysis tool reports this warning when the annotation for the function contains more Externals than the actual number of parameters.
</description>
</rule>
<rule>
<key>C28291</key>
<configkey>C28291</configkey>
<priority>CRITICAL</priority>
<name>warning C28291: Post null/notnull at deref level 0 is meaningless for function <x> at param <number></name>
<description>
The Code Analysis tool reports this warning when the post condition of a dereference level-zero parameter is specified to have a null/non-null property. This error occurs because a value at dereference level zero cannot change.
</description>
</rule>
<rule>
<key>C28300</key>
<configkey>C28300</configkey>
<priority>CRITICAL</priority>
<name>warning C28300: <parameter_name>: Expression operands of incompatible types for operator <operator_name></name>
<description>
This warning is reported when operand types in a parameter are not compatible with the operator.
</description>
</rule>
<rule>
<key>C28301</key>
<configkey>C28301</configkey>
<priority>CRITICAL</priority>
<name>warning C28301: No annotations for first declaration of <function>.<note1> See <filename>(<line>). <note2></name>
<description>
This warning is reported when annotations were not found at the first declaration of a given function.
</description>
</rule>
<rule>
<key>C28302</key>
<configkey>C28302</configkey>
<priority>CRITICAL</priority>
<name>warning C28302: For C++ reference-parameter <parameter_name>, an extra _Deref_ operator was found on <annotation>.</name>
<description>
This warning is reported when an extra level of _Deref_ is used on a parameter.
SAL2 does not require the use of an extra level of _Deref_ when dealing with reference parameters. This particular annotation is unambiguous and is interpreted correctly, but should be corrected.
Frequently this can be corrected by simply removing the older __deref annotation and using SAL2 syntax. Sometimes may be necessary to use _At_ to reference the specific object to be annotated.
</description>
</rule>
<rule>
<key>C28303</key>
<configkey>C28303</configkey>
<priority>CRITICAL</priority>
<name>warning C28303: For C++ reference-parameter <parameter_name>, an ambiguous _Deref_ operator was found on <annotation>.</name>
<description>
This warning similar to warning C28302 and is reported when an extra level of _Deref_ is used on a parameter.
SAL2 does not require the use of an extra level of _Deref_ when dealing with reference parameters. This particular annotation is ambiguous as to which level of dereference is intended to be annotated. It may be necessary to use _At_ to reference the specific object to be annotated.
</description>
</rule>
<rule>
<key>C28304</key>
<configkey>C28304</configkey>
<priority>CRITICAL</priority>
<name>warning C28304: For C++ reference-parameter <parameter_name>, an improperly placed _Notref_ operator was found applied to <token>.</name>
<description>
The _Notref_ operator should only be used in special circumstances involving C++ reference parameters and only in system-provided macros. It must be immediately followed by a _Deref_ operator or a functional annotation.
</description>
</rule>
<rule>
<key>C28305</key>
<configkey>C28305</configkey>
<priority>CRITICAL</priority>
<name>warning C28305: An error while parsing <token> was discovered.</name>
<description>
This warning is reported when the expression containing the specified token is ill-formed.
</description>
</rule>
<rule>
<key>C28306</key>
<configkey>C28306</configkey>
<priority>CRITICAL</priority>
<name>warning C28306: The annotation on parameter is obsolescent</name>
<description>
Use _String_length_ with the appropriate SAL2 annotation instead.
</description>
</rule>
<rule>
<key>C28307</key>
<configkey>C28307</configkey>
<priority>CRITICAL</priority>
<name>warning C28307: The annotation on parameter is obsolescent</name>
<description>
Use _String_length_ with the appropriate SAL2 annotation instead.
</description>
</rule>
<rule>
<key>C28308</key>
<configkey>C28308</configkey>
<priority>CRITICAL</priority>
<name>warning C28308: The format list argument position specified by the annotation is incorrect. </name>
<description>
The format list argument position must be either a parameter name, or an integer offset that's in the parameter list, or zero.
The second parameter to IsFormatString2 (where) can be in one of two forms:
- A parameter name, which is taken as the first argument to the format string.
- An offset (n) relative to the format-string parameter.
In the second form, the first format-string parameter is the n-th argument after the format string. If n is zero, an ellipsis is specified as the parameter. Specifying an offset of zero without specifying the ellipsis as the first format-string parameter will cause an error.
</description>
</rule>
<rule>
<key>C28309</key>
<configkey>C28309</configkey>
<priority>CRITICAL</priority>
<name>warning C28309: <parameter_name>: Annotation operands must be integer/enum/pointer types. Floats are approximated as integers. Types: <typelist>.</name>
<description>
warning C28309: <parameter_name>: Annotation operands must be integer/enum/pointer types. Void operands and C++ overloaded operators are not supported. Floats are approximated as integers. Types: <typelist>.
You’ve tried to use a void or a function in an annotation expression, and Code Analysis can't handle it. This error typically occurs when an operator== that's implemented as a function is used, but other cases may also occur. Examine the types in <typelist> for clues about what’s wrong.
</description>
</rule>
<rule>
<key>C28350</key>
<configkey>C28350</configkey>
<priority>CRITICAL</priority>
<name>warning C28350: The annotation <annotation> describes a situation that is not conditionally applicable.</name>
<description>
Usually this warning is generated when an annotation is applied where the C/C++ type is being inspected.
</description>
</rule>
<rule>
<key>C28351</key>
<configkey>C28351</configkey>
<priority>CRITICAL</priority>
<name>warning C28351: The annotation <annotation> describes where a dynamic value (a variable) cannot be used in the condition.</name>
<description>
This warning is reported when an annotation is applied where the C/C++ type is being inspected.
The expression in the _When_ should evaluate to a constant. The _When_ is ignored.
</description>
</rule>
</rules>
