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>1</key>
<configkey>1</configkey>
<priority>CRITICAL</priority>
<name>Unclosed Comment (Location)</name>
<description>End of file was reached with an open comment still unclosed. The Location of the open comment is shown.</description>
</rule>
<rule>
<key>2</key>
<configkey>2</configkey>
<priority>CRITICAL</priority>
<name>Unclosed Quote</name>
<description>An end of line was reached and a matching quote character (single or double) to an earlier quote character on the same line was not found.</description>
</rule>
<rule>
<key>3</key>
<configkey>3</configkey>
<priority>CRITICAL</priority>
<name>#else without a #if</name>
<description>A #else was encountered not in the scope of a #if, #ifdef or #ifndef.</description>
</rule>
<rule>
<key>4</key>
<configkey>4</configkey>
<priority>CRITICAL</priority>
<name>Too many #if levels</name>
<description>An internal limit was reached on the level of nesting of #if statements (including #ifdef and #ifndef).</description>
</rule>
<rule>
<key>5</key>
<configkey>5</configkey>
<priority>CRITICAL</priority>
<name>Too many #endif's</name>
<description>A #endif was encountered not in the scope of a #if or #ifdef or #ifndef.</description>
</rule>
<rule>
<key>6</key>
<configkey>6</configkey>
<priority>CRITICAL</priority>
<name>Stack Overflow</name>
<description>One of the built-in non-extendable stacks has been overextended. The possibilities are too many nested #if statements, #includes statements (including all recursive #include statements), static blocks (bounded by braces) or #define replacements.</description>
</rule>
<rule>
<key>7</key>
<configkey>7</configkey>
<priority>CRITICAL</priority>
<name>Unable to open include file: FileName</name>
<description>FileName is the name of the include file which could not be opened.</description>
</rule>
<rule>
<key>8</key>
<configkey>8</configkey>
<priority>CRITICAL</priority>
<name>Unclosed #if (Location)</name>
<description>A #if (or #ifdef or #ifndef) was encountered without a corresponding #endif. Location is the location of the #if.</description>
</rule>
<rule>
<key>9</key>
<configkey>9</configkey>
<priority>CRITICAL</priority>
<name>Too many #else's in #if (Location)</name>
<description>A given #if contained a #else which in turn was followed by either another #else or a #elif. The error message gives the line of the #if statement that started the conditional that contained the aberration.</description>
</rule>
<rule>
<key>10</key>
<configkey>10</configkey>
<priority>CRITICAL</priority>
<name>Expecting 'String'</name>
<description>String is the expected token. The expected token could not be found. This is commonly given when certain reserved words are not recognized. int __interrupt f(); will receive an Expecting ';' message at the f because it thinks you just declared __interrupt. The cure is to establish a new reserved word with +rw(__interrupt). Also, make sure you are using the correct compiler options file.</description>
</rule>
<rule>
<key>11</key>
<configkey>11</configkey>
<priority>CRITICAL</priority>
<name>Excessive Size</name>
<description>The filename specified on a #include line had a length that exceeded FILENAME_MAX characters.</description>
</rule>
<rule>
<key>12</key>
<configkey>12</configkey>
<priority>CRITICAL</priority>
<name>Need < or "</name>
<description>After a #include is detected and after macro substitution is performed, a file specification of the form <filename> or "filename" is expected.</description>
</rule>
<rule>
<key>13</key>
<configkey>13</configkey>
<priority>CRITICAL</priority>
<name>Bad type</name>
<description>A type adjective such as long, unsigned, etc. cannot be applied to the type which follows.</description>
</rule>
<rule>
<key>14</key>
<configkey>14</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Symbol' previously defined (Location)</name>
<description>The named object has been defined a second time. The location of the previous definition is provided. If this is a tentative definition (no initializer) then the message can be suppressed with the +fmd flag.</description>
</rule>
<rule>
<key>15</key>
<configkey>15</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Symbol' redeclared (TypeDiff) (Location)</name>
<description>The named symbol has been previously declared or defined in some other module (location given) with a type different from the type given by the declaration at the current location. The parameter TypeDiff provides further information on how the types differ.</description>
</rule>
<rule>
<key>16</key>
<configkey>16</configkey>
<priority>CRITICAL</priority>
<name>Unrecognized name</name>
<description>A # directive is not followed by a recognizable word. If this is not an error, use the +ppw option.</description>
</rule>
<rule>
<key>17</key>
<configkey>17</configkey>
<priority>CRITICAL</priority>
<name>Unrecognized name</name>
<description>A non-parameter is being declared where only parameters should be.</description>
</rule>
<rule>
<key>18</key>
<configkey>18</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Symbol' redeclared (TypeDiff) conflicts with Location</name>
<description>A symbol is being redeclared. The parameter TypeDiff provides further information on how the types differ. Location is the location of the previous definition.</description>
</rule>
<rule>
<key>19</key>
<configkey>19</configkey>
<priority>CRITICAL</priority>
<name>Useless Declaration</name>
<description>A type appeared by itself without an associated variable, and the type was not a struct and not a union and not an enum. A double semi-colon can cause this as in:
int x;;</description>
</rule>
<rule>
<key>20</key>
<configkey>20</configkey>
<priority>CRITICAL</priority>
<name>Illegal use of =</name>
<description>A function declaration was followed by an = sign.</description>
</rule>
<rule>
<key>21</key>
<configkey>21</configkey>
<priority>CRITICAL</priority>
<name>Expected {</name>
<description>An initializer for an indefinite size array must begin with a left brace.</description>
</rule>
<rule>
<key>22</key>
<configkey>22</configkey>
<priority>CRITICAL</priority>
<name>Illegal operator</name>
<description>A unary operator was found following an operand and the operator is not a post operator.</description>
</rule>
<rule>
<key>23</key>
<configkey>23</configkey>
<priority>CRITICAL</priority>
<name>Expected colon</name>
<description>A ? operator was encountered but this was not followed by a : as was expected.</description>
</rule>
<rule>
<key>24</key>
<configkey>24</configkey>
<priority>CRITICAL</priority>
<name>Expected an expression, found 'String'</name>
<description>An operator was found at the start of an expression but it was not a unary operator.</description>
</rule>
<rule>
<key>25</key>
<configkey>25</configkey>
<priority>CRITICAL</priority>
<name>Illegal constant</name>
<description>Too many characters were encountered in a character constant (a constant bounded by ' marks).</description>
</rule>
<rule>
<key>26</key>
<configkey>26</configkey>
<priority>CRITICAL</priority>
<name>Expected an expression, found 'String'</name>
<description>An expression was not found where one was expected. The unexpected token is placed in the message.</description>
</rule>
<rule>
<key>27</key>
<configkey>27</configkey>
<priority>CRITICAL</priority>
<name>Illegal character (0xhh)</name>
<description>An illegal character was found in the source code. The hex code is provided in the message. A blank is assumed. If you are using strange characters in identifier names you will get this message for which you may use the -ident option.</description>
</rule>
<rule>
<key>28</key>
<configkey>28</configkey>
<priority>CRITICAL</priority>
<name>Redefinition of symbol 'Symbol' Location</name>
<description>The identifier preceding a colon was previously declared at the Location given as not being a label.</description>
</rule>
<rule>
<key>30</key>
<configkey>30</configkey>
<priority>CRITICAL</priority>
<name>Expected a constant</name>
<description>A constant was expected but not obtained. This could be following a case keyword, an array dimension, bit field length, enumeration value, #if expression, etc.</description>
</rule>
<rule>
<key>31</key>
<configkey>31</configkey>
<priority>CRITICAL</priority>
<name>Redefinition of symbol 'Symbol' conflicts with Location</name>
<description>A data object or function previously defined in this module is being redefined.</description>
</rule>
<rule>
<key>32</key>
<configkey>32</configkey>
<priority>CRITICAL</priority>
<name>Field size (member 'Symbol') should not be zero</name>
<description>The length of a field was given as non-positive, (0 or negative).</description>
</rule>
<rule>
<key>33</key>
<configkey>33</configkey>
<priority>CRITICAL</priority>
<name>Illegal constant</name>
<description>A constant was badly formed as when an octal constant contains one of the digits 8 or 9.</description>
</rule>
<rule>
<key>34</key>
<configkey>34</configkey>
<priority>CRITICAL</priority>
<name>Non-constant initializer</name>
<description>A non-constant initializer was found for a static data item.</description>
</rule>
<rule>
<key>35</key>
<configkey>35</configkey>
<priority>CRITICAL</priority>
<name>Initializer has side-effects</name>
<description>An initializer with side effects was found for a static data item.</description>
</rule>
<rule>
<key>36</key>
<configkey>36</configkey>
<priority>CRITICAL</priority>
<name>Redefining the storage class of symbol 'Symbol' conflicts with Location</name>
<description>An object's storage class is being changed.</description>
</rule>
<rule>
<key>37</key>
<configkey>37</configkey>
<priority>CRITICAL</priority>
<name>Value of enumerator 'Symbol' inconsistent (conflicts with Location)</name>
<description>An enumerator was inconsistently valued.</description>
</rule>
<rule>
<key>38</key>
<configkey>38</configkey>
<priority>CRITICAL</priority>
<name>Offset of symbol 'Symbol' inconsistent (Location)</name>
<description>A member of a class or struct appears in a different position (offset from the start of the structure) than an earlier declaration. This could be caused by array dimensions changing from one module to another.</description>
</rule>
<rule>
<key>39</key>
<configkey>39</configkey>
<priority>CRITICAL</priority>
<name>Redefinition of symbol 'Symbol' conflicts with Location</name>
<description>A struct or union is being redefined.</description>
</rule>
<rule>
<key>40</key>
<configkey>40</configkey>
<priority>CRITICAL</priority>
<name>Undeclared identifier 'Name'</name>
<description>Within an expression, an identifier was encountered that had not previously been declared and was not followed by a left parenthesis. Name is the name of the identifier.</description>
</rule>
<rule>
<key>41</key>
<configkey>41</configkey>
<priority>CRITICAL</priority>
<name>Redefinition of symbol 'Symbol'</name>
<description>A parameter of either a function or a macro is being repeated.</description>
</rule>
<rule>
<key>42</key>
<configkey>42</configkey>
<priority>CRITICAL</priority>
<name>Expected a statement</name>
<description>A statement was expected but a token was encountered that could not possibly begin a statement.</description>
</rule>
<rule>
<key>43</key>
<configkey>43</configkey>
<priority>CRITICAL</priority>
<name>Vacuous type for variable 'Symbol'</name>
<description>A vacuous type was found such as the void type in a context that expected substance.</description>
</rule>
<rule>
<key>44</key>
<configkey>44</configkey>
<priority>CRITICAL</priority>
<name>Need a switch</name>
<description>A case or default statement occurred outside a switch.</description>
</rule>
<rule>
<key>45</key>
<configkey>45</configkey>
<priority>CRITICAL</priority>
<name>Bad use of register</name>
<description>A variable is declared as a register but its type is inconsistent with it being a register (such as a function).</description>
</rule>
<rule>
<key>46</key>
<configkey>46</configkey>
<priority>CRITICAL</priority>
<name>Field type should be int</name>
<description>Bit fields in a structure should be typed unsigned or int. If your compiler allows other kinds of objects, such as char, then simply suppress this message.</description>
</rule>
<rule>
<key>47</key>
<configkey>47</configkey>
<priority>CRITICAL</priority>
<name>Bad type</name>
<description>Unary minus requires an arithmetic operand.</description>
</rule>
<rule>
<key>48</key>
<configkey>48</configkey>
<priority>CRITICAL</priority>
<name>Bad type</name>
<description>Unary * or the left hand side of the ptr (->) operator requires a pointer operand.</description>
</rule>
<rule>
<key>49</key>
<configkey>49</configkey>
<priority>CRITICAL</priority>
<name>Expected a type</name>
<description>Only types are allowed within prototypes. A prototype is a function declaration with a sequence of types within parentheses. The processor is at a state where it has detected at least one type within parentheses and so is expecting more types or a closing right parenthesis.</description>
</rule>
<rule>
<key>50</key>
<configkey>50</configkey>
<priority>CRITICAL</priority>
<name>Attempted to take the address of a non-lvalue</name>
<description>Unary & operator requires an lvalue (a value suitable for placement on the left hand side of an assignment operator).</description>
</rule>
<rule>
<key>51</key>
<configkey>51</configkey>
<priority>CRITICAL</priority>
<name>Expected integral type</name>
<description>Unary ~ expects an integral type (signed or unsigned char, short, int, or long).</description>
</rule>
<rule>
<key>52</key>
<configkey>52</configkey>
<priority>CRITICAL</priority>
<name>Expected an lvalue</name>
<description>autodecrement (--) and autoincrement (++) operators require an lvalue (a value suitable for placement on the left hand side of an assignment operator). Remember that casts do not normally produce lvalues. Thus
++(char *)p;
is illegal according to the ANSI standard. This construct is allowed by some compilers and is allowed if you use the +fpc option (Pointer Casts are lvalues).</description>
</rule>
<rule>
<key>53</key>
<configkey>53</configkey>
<priority>CRITICAL</priority>
<name>Expected a scalar</name>
<description>Autodecrement (--) and autoincrement (++) operators may only be applied to scalars (arithmetics and pointers) or to objects for which these operators have been defined.</description>
</rule>
<rule>
<key>54</key>
<configkey>54</configkey>
<priority>CRITICAL</priority>
<name>Division by 0</name>
<description>The constant 0 was used on the right hand side of the division operator (/) or the remainder operator (%).</description>
</rule>
<rule>
<key>55</key>
<configkey>55</configkey>
<priority>CRITICAL</priority>
<name>Bad type</name>
<description>The context requires a scalar, function, array, or struct (unless -fsa).</description>
</rule>
<rule>
<key>56</key>
<configkey>56</configkey>
<priority>CRITICAL</priority>
<name>Bad type</name>
<description>Add/subtract operator requires scalar types and pointers may not be added to pointers.</description>
</rule>
<rule>
<key>57</key>
<configkey>57</configkey>
<priority>CRITICAL</priority>
<name>Bad type</name>
<description>Bit operators ( &, | and ^ ) require integral arguments.</description>
</rule>
<rule>
<key>58</key>
<configkey>58</configkey>
<priority>CRITICAL</priority>
<name>Bad type</name>
<description>Bad arguments were given to a relational operator; these always require two scalars and pointers can't be compared with integers (unless constant 0).</description>
</rule>
<rule>
<key>59</key>
<configkey>59</configkey>
<priority>CRITICAL</priority>
<name>Bad type</name>
<description>The amount by which an item can be shifted must be integral.</description>
</rule>
<rule>
<key>60</key>
<configkey>60</configkey>
<priority>CRITICAL</priority>
<name>Bad type</name>
<description>The value to be shifted must be integral.</description>
</rule>
<rule>
<key>61</key>
<configkey>61</configkey>
<priority>CRITICAL</priority>
<name>Bad type</name>
<description>The context requires a Boolean. Booleans must be some form of arithmetic or pointer.</description>
</rule>
<rule>
<key>62</key>
<configkey>62</configkey>
<priority>CRITICAL</priority>
<name>Incompatible types (TypeDiff) for operator ':'</name>
<description>The 2nd and 3rd arguments to ? : must be compatible types.</description>
</rule>
<rule>
<key>63</key>
<configkey>63</configkey>
<priority>CRITICAL</priority>
<name>Expected an lvalue</name>
<description>Assignment expects its first operand to be an lvalue. Please note that a cast removes the lvaluedness of an expression.</description>
</rule>
<rule>
<key>64</key>
<configkey>64</configkey>
<priority>CRITICAL</priority>
<name>Type mismatch (Context) (TypeDiff)</name>
<description>There was a mismatch in types across an assignment (or implied assignment, see Context). TypeDiff specifies the type difference.</description>
</rule>
<rule>
<key>65</key>
<configkey>65</configkey>
<priority>CRITICAL</priority>
<name>Expected a member name</name>
<description>After a dot (.) or pointer (->) operator a member name should appear.</description>
</rule>
<rule>
<key>66</key>
<configkey>66</configkey>
<priority>CRITICAL</priority>
<name>Bad type</name>
<description>A void type was employed where it is not permitted. If a void type is placed in a prototype then it must be the only type within a prototype. (See error number 49.)</description>
</rule>
<rule>
<key>67</key>
<configkey>67</configkey>
<priority>CRITICAL</priority>
<name>Can't cast from Type to Type</name>
<description>Attempt to cast a non-scalar to an integral.</description>
</rule>
<rule>
<key>68</key>
<configkey>68</configkey>
<priority>CRITICAL</priority>
<name>Can't cast from Type to Type</name>
<description>Attempt to cast a non-arithmetic to a float.</description>
</rule>
<rule>
<key>69</key>
<configkey>69</configkey>
<priority>CRITICAL</priority>
<name>Can't cast from Type to Type</name>
<description>Bad conversion involving incompatible structures or a structure and some other object.</description>
</rule>
<rule>
<key>70</key>
<configkey>70</configkey>
<priority>CRITICAL</priority>
<name>Can't cast from Type to Type</name>
<description>Attempt to cast to a pointer from an unusual type (non-integral).</description>
</rule>
<rule>
<key>71</key>
<configkey>71</configkey>
<priority>CRITICAL</priority>
<name>Can't cast from Type to Type</name>
<description>Attempt to cast to a type that does not allow conversions.</description>
</rule>
<rule>
<key>72</key>
<configkey>72</configkey>
<priority>CRITICAL</priority>
<name>Bad option 'String'</name>
<description>Was not able to interpret an option. The option is given in String.</description>
</rule>
<rule>
<key>73</key>
<configkey>73</configkey>
<priority>CRITICAL</priority>
<name>Bad left operand</name>
<description>The cursor is positioned at or just beyond either an -> or a . operator. These operators expect an expression primary on their left. Please enclose any complex expression in this position within parentheses.</description>
</rule>
<rule>
<key>74</key>
<configkey>74</configkey>
<priority>CRITICAL</priority>
<name>Address of Register</name>
<description>An attempt was made to apply the address (&) operator to a variable whose storage class was given as register.</description>
</rule>
<rule>
<key>75</key>
<configkey>75</configkey>
<priority>CRITICAL</priority>
<name>Too late to change sizes (option 'String')</name>
<description>The size option was given after all or part of a module was processed. Make sure that any option to reset sizes of objects be done at the beginning of the first module processed or on the command line before any module is processed.</description>
</rule>
<rule>
<key>76</key>
<configkey>76</configkey>
<priority>CRITICAL</priority>
<name>can't open file String</name>
<description>String is the name of the file. The named file could not be opened for output. The file was destined to become a PC-lint/FlexeLint object module.</description>
</rule>
<rule>
<key>77</key>
<configkey>77</configkey>
<priority>CRITICAL</priority>
<name>Address of bit-field cannot be taken</name>
<description>The address of a bit-field cannot be taken. The rules of C only allow for taking the address of a whole byte (a whole char).</description>
</rule>
<rule>
<key>78</key>
<configkey>78</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Symbol' typedef'ed at Location used in expression</name>
<description>The named symbol was defined in a typedef statement and is therefore considered a type. It was subsequently found in a context where an expression was expected.</description>
</rule>
<rule>
<key>79</key>
<configkey>79</configkey>
<priority>CRITICAL</priority>
<name>Bad type for % operator</name>
<description>The % operator should be used with some form of integer.</description>
</rule>
<rule>
<key>80</key>
<configkey>80</configkey>
<priority>CRITICAL</priority>
<name>this use of ellipsis is not strictly ANSI</name>
<description>The ellipsis should be used in a prototype only after a sequence of types not after a sequence of identifiers. Some compilers support this extension. If you want to use this feature suppress this message.</description>
</rule>
<rule>
<key>81</key>
<configkey>81</configkey>
<priority>CRITICAL</priority>
<name>struct/union not permitted in equality comparison</name>
<description>Two struct's or union's are being compared with one of == or !=. This is not permitted by the ANSI standard. If your compiler supports this, suppress this message.</description>
</rule>
<rule>
<key>82</key>
<configkey>82</configkey>
<priority>CRITICAL</priority>
<name>return <exp>; illegal with void function</name>
<description>The ANSI standard does not allow an expression form of the return statement with a void function. If you are trying to cast to void as in return (void)f(); and your compiler allows it, suppress this message.</description>
</rule>
<rule>
<key>83</key>
<configkey>83</configkey>
<priority>CRITICAL</priority>
<name>Incompatible pointer types with subtraction</name>
<description>Two pointers being subtracted have indirect types which differ. You can get PC-lint/FlexeLint to ignore slight differences in the pointers by employing one or more of the -ep... options.</description>
</rule>
<rule>
<key>84</key>
<configkey>84</configkey>
<priority>CRITICAL</priority>
<name>sizeof object is zero or object is undefined</name>
<description>A sizeof returned a 0 value. This could happen if the object were undefined or incompletely defined. Make sure a complete definition of the object is in scope when you use sizeof.</description>
</rule>
<rule>
<key>85</key>
<configkey>85</configkey>
<priority>CRITICAL</priority>
<name>Array 'Symbol' has dimension 0</name>
<description>An array (named Symbol) was declared without a dimension in a context that required a non-zero dimension.</description>
</rule>
<rule>
<key>86</key>
<configkey>86</configkey>
<priority>CRITICAL</priority>
<name>Structure 'Symbol' has no data elements</name>
<description>A structure was declared (in a C module) that had no data members. Though legal in C++ this is not legal C.</description>
</rule>
<rule>
<key>87</key>
<configkey>87</configkey>
<priority>CRITICAL</priority>
<name>Expression too complicated for #ifdef or #ifndef</name>
<description>By the rules of C there should be only a single identifier following a #ifdef or a #ifndef. You may also supply a validly constructed C (or C++) comment.</description>
</rule>
<rule>
<key>88</key>
<configkey>88</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Symbol' is an array of empty elements</name>
<description>An array was declared (in a C module) whose elements were each of 0 length. Though legal in C++ this is not permitted C.</description>
</rule>
<rule>
<key>89</key>
<configkey>89</configkey>
<priority>CRITICAL</priority>
<name>Argument or option too long ('String')</name>
<description>The length of an option (shown in String) exceeds an internal limit. Please try to decompose the option into something smaller. At this writing the limit is 610 characters.</description>
</rule>
<rule>
<key>90</key>
<configkey>90</configkey>
<priority>CRITICAL</priority>
<name>Option 'String' is only appropriate within a lint comment</name>
<description>The indicated option is not appropriate at the command or the .lnt level. For example if -unreachable is given on the command line you will get this message.</description>
</rule>
<rule>
<key>91</key>
<configkey>91</configkey>
<priority>CRITICAL</priority>
<name>Line exceeds Integer characters (use +linebuf)</name>
<description>A line read from one of the input files is longer than anticipated. By default the line buffer size is 600 characters. Each time you use the +linebuf option you can double this size. The size can be doubled ad infinitum.</description>
</rule>
<rule>
<key>92</key>
<configkey>92</configkey>
<priority>CRITICAL</priority>
<name>Negative array dimension or bit field length (Integer)</name>
<description>A negative array dimension or bit field length is not permitted.</description>
</rule>
<rule>
<key>93</key>
<configkey>93</configkey>
<priority>CRITICAL</priority>
<name>New-line is not permitted within string arguments to macros</name>
<description>A macro invocation contains a string that is split across more than one line. For example: A( "Hello World" );
will trigger this message. Some compilers accept this construct and you can suppress this message with -e93 if this is your current practice. But it is more portable to place the string constant on one line. Thus
A( "Hello World" );
would be better.</description>
</rule>
<rule>
<key>95</key>
<configkey>95</configkey>
<priority>CRITICAL</priority>
<name>Expected a macro parameter but instead found 'Name'</name>
<description>The # operator (or the non-standard extension to the # operator spelled #@) was found within a macro definition but was not immediately followed by a parameter of the macro as is required by the standards. Name identifies the token immediately to the right of the operator.</description>
</rule>
<rule>
<key>96</key>
<configkey>96</configkey>
<priority>CRITICAL</priority>
<name>Unmatched left brace for String on Location</name>
<description>The purpose of this message is to report the location of a left curly brace that is unmatched by a right curly brace. Such an unmatched left curly can be far removed from the point at which the unbalance was detected (often the end of the compilation unit). Providing the location of the left curly can be extremely helpful in determining the source of the imbalance.</description>
</rule>
<rule>
<key>98</key>
<configkey>98</configkey>
<priority>CRITICAL</priority>
<name>Recovery Error (String)</name>
<description>A recovery error is issued when an inconsistent state was found while attempting to recover from a syntactic error. The String provided in the message serves as a clue to this inconsistent state. Since the presumptive cause of the error is an earlier error, priority should be placed on resolving the original error. This "Recovery Error" is meant only to provide additional information on the state of the parser.</description>
</rule>
<rule>
<key>101</key>
<configkey>101</configkey>
<priority>CRITICAL</priority>
<name>Expected an identifier</name>
<description>While processing a function declarator, a parameter specifier was encountered that was not an identifier, whereas a prior parameter was specified as an identifier. This is mixing old-style function declarations with the new-style and is not permitted. For example
void f(n,int m)
will elicit this message.</description>
</rule>
<rule>
<key>102</key>
<configkey>102</configkey>
<priority>CRITICAL</priority>
<name>Illegal parameter specification</name>
<description>Within a function declarator, a parameter must be specified as either an identifier or as a type followed by a declarator.</description>
</rule>
<rule>
<key>103</key>
<configkey>103</configkey>
<priority>CRITICAL</priority>
<name>Unexpected declaration</name>
<description>After a prototype, only a comma, semi-colon, right parenthesis or a left brace may occur. This error could occur if you have omitted a terminating character after a declaration or if you are mixing old-style parameter declarations with new-style prototypes.</description>
</rule>
<rule>
<key>104</key>
<configkey>104</configkey>
<priority>CRITICAL</priority>
<name>Conflicting types</name>
<description>Two consecutive conflicting types were found such as int followed by double. Remove one of the types!</description>
</rule>
<rule>
<key>105</key>
<configkey>105</configkey>
<priority>CRITICAL</priority>
<name>Conflicting modifiers</name>
<description>Two consecutive conflicting modifiers were found such as far followed by near. Remove one of the modifiers!</description>
</rule>
<rule>
<key>106</key>
<configkey>106</configkey>
<priority>CRITICAL</priority>
<name>Illegal constant</name>
<description>A string constant was found within a preprocessor expression as in
#if ABC == "abc"
Such expressions should be integral expressions.</description>
</rule>
<rule>
<key>107</key>
<configkey>107</configkey>
<priority>CRITICAL</priority>
<name>Label 'Symbol' (Location) not defined</name>
<description>The Symbol at the given Location appeared in a goto but there was no corresponding label.</description>
</rule>
<rule>
<key>108</key>
<configkey>108</configkey>
<priority>CRITICAL</priority>
<name>Invalid context</name>
<description>A continue or break statement was encountered without an appropriate surrounding context such as a for, while, or do loop or, for the break statement only, a surrounding switch statement.</description>
</rule>
<rule>
<key>109</key>
<configkey>109</configkey>
<priority>CRITICAL</priority>
<name>The combination 'short long' is not standard, 'long' is assumed</name>
<description>Some compilers support the non-standard sequence short long. This message reports, as an error, that this sequence is being used. If you are required to use the construct then simply suppress this message. As the message indicates, that type will be presumed to be long.</description>
</rule>
<rule>
<key>110</key>
<configkey>110</configkey>
<priority>CRITICAL</priority>
<name>Attempt to assign to void</name>
<description>An attempt was made to assign a value to an object designated (possibly through a pointer) as void.</description>
</rule>
<rule>
<key>111</key>
<configkey>111</configkey>
<priority>CRITICAL</priority>
<name>Assignment to const object</name>
<description>An object declared as const was assigned a value. This could arise via indirection. For example, if p is a pointer to a const int then assigning to *p will raise this error.</description>
</rule>
<rule>
<key>113</key>
<configkey>113</configkey>
<priority>CRITICAL</priority>
<name>Inconsistent enum declaration</name>
<description>The sequence of members within an enum (or their values) is inconsistent with that of another enum (usually in some other module) having the same name.</description>
</rule>
<rule>
<key>114</key>
<configkey>114</configkey>
<priority>CRITICAL</priority>
<name>Inconsistent structure declaration for tag 'Symbol'</name>
<description>The sequence of members within a structure (or union) is inconsistent with another structure (usually in some other module) having the same name.</description>
</rule>
<rule>
<key>115</key>
<configkey>115</configkey>
<priority>CRITICAL</priority>
<name>Struct/union not defined</name>
<description>A reference to a structure or a union was made that required a definition and there is no definition in scope. For example, a reference to p->a where p is a pointer to a struct that had not yet been defined in the current module.</description>
</rule>
<rule>
<key>116</key>
<configkey>116</configkey>
<priority>CRITICAL</priority>
<name>Inappropriate storage class</name>
<description>A storage class other than register was given in a section of code that is dedicated to declaring parameters. The section is that part of a function preceding the first left brace.</description>
</rule>
<rule>
<key>117</key>
<configkey>117</configkey>
<priority>CRITICAL</priority>
<name>Inappropriate storage class</name>
<description>A storage class was provided outside any function that indicated either auto or register. Such storage classes are appropriate only within functions.</description>
</rule>
<rule>
<key>118</key>
<configkey>118</configkey>
<priority>CRITICAL</priority>
<name>Too few arguments for prototype</name>
<description>The number of arguments provided for a function was less than the number indicated by a prototype in scope.</description>
</rule>
<rule>
<key>119</key>
<configkey>119</configkey>
<priority>CRITICAL</priority>
<name>Too many arguments for prototype</name>
<description>The number of arguments provided for a function was greater than the number indicated by a prototype in scope.</description>
</rule>
<rule>
<key>120</key>
<configkey>120</configkey>
<priority>CRITICAL</priority>
<name>Initialization without braces of dataless type 'Symbol'</name>
<description>There was an attempt to initialize a nested object (e.g., an array element) without braces. Additionally, that object type possesses no data members. class A { public: void f(); }; class B { public: A a; int k; } ; A a[4] = { {}, {}, {}, {} }; // OK B b = { , 34 }; // Error 120</description>
</rule>
<rule>
<key>121</key>
<configkey>121</configkey>
<priority>CRITICAL</priority>
<name>Attempting to initialize an object of undefined type 'Symbol'</name>
<description>The initialization of an object was attempted where that object type has no visible definition. For example: class Undefined u = { 5 };</description>
</rule>
<rule>
<key>122</key>
<configkey>122</configkey>
<priority>CRITICAL</priority>
<name>Digit (Char) too large for radix</name>
<description>The indicated character was found in a constant beginning with zero. For example, 08 is accepted by some compilers to represent 8 but it should be 010 or plain 8.</description>
</rule>
<rule>
<key>123</key>
<configkey>123</configkey>
<priority>CRITICAL</priority>
<name>Macro 'Symbol' defined with arguments at Location this is just a warning</name>
<description>The name of a macro defined with arguments was subsequently used without a following '('. This is legal but may be an oversight. It is not uncommon to suppress this message (with -e123), because some compilers allow, for example, the macro max() to coexist with a variable max.</description>
</rule>
<rule>
<key>124</key>
<configkey>124</configkey>
<priority>CRITICAL</priority>
<name>Pointer to void not allowed</name>
<description>A pointer to void was used in a context that does not permit void. This includes subtraction, addition and the relationals (> >= < <=).</description>
</rule>
<rule>
<key>125</key>
<configkey>125</configkey>
<priority>CRITICAL</priority>
<name>Too many storage class specifiers</name>
<description>More than one storage class specifier (static, extern, typedef, register or auto) was found. Only one is permitted.</description>
</rule>
<rule>
<key>126</key>
<configkey>126</configkey>
<priority>CRITICAL</priority>
<name>Inconsistent structure definition 'Symbol'</name>
<description>The named structure (or union or enum) was inconsistently defined across modules. The inconsistency was recognized while processing a lint object module. Line number information was not available with this message. Alter the structures so that the member information is consistent.</description>
</rule>
<rule>
<key>127</key>
<configkey>127</configkey>
<priority>CRITICAL</priority>
<name>Illegal constant</name>
<description>An empty character constant ('') was found.</description>
</rule>
<rule>
<key>128</key>
<configkey>128</configkey>
<priority>CRITICAL</priority>
<name>Pointer to function not allowed</name>
<description>A pointer to a function was found in an arithmetic context such as subtraction, addition, or one of the relationals (> >= < <=).</description>
</rule>
<rule>
<key>129</key>
<configkey>129</configkey>
<priority>CRITICAL</priority>
<name>declaration expected, identifier 'Symbol' ignored</name>
<description>In a context in which a declaration was expected an identifier was found. Moreover, the identifier was not followed by '(' or a '['</description>
</rule>
<rule>
<key>130</key>
<configkey>130</configkey>
<priority>CRITICAL</priority>
<name>Expected integral type</name>
<description>The expression in a switch statement must be some variation of an int (possibly long or unsigned) or an enum.</description>
</rule>
<rule>
<key>131</key>
<configkey>131</configkey>
<priority>CRITICAL</priority>
<name>syntax error in call of macro 'Symbol' at location Location</name>
<description>This message is issued when a macro with arguments (function-like macro) is invoked and an incorrect number of arguments is provided. Location is the location of the start of the macro call. This can be useful because an errant macro call can extend over many lines.</description>
</rule>
<rule>
<key>132</key>
<configkey>132</configkey>
<priority>CRITICAL</priority>
<name>Expected function definition</name>
<description>A function declaration with identifiers between parentheses is the start of an old-style function definition (K&R style). This is normally followed by optional declarations and a left brace to signal the start of the function body. Either replace the identifier(s) with type(s) or complete the function with a function body.</description>
</rule>
<rule>
<key>133</key>
<configkey>133</configkey>
<priority>CRITICAL</priority>
<name>Too many initializers for aggregate 'Symbol'</name>
<description>In a brace-enclosed initializer, there are more items than there are elements of the aggregate.</description>
</rule>
<rule>
<key>134</key>
<configkey>134</configkey>
<priority>CRITICAL</priority>
<name>Missing initializer</name>
<description>An initializer was expected but only a comma was present.</description>
</rule>
<rule>
<key>135</key>
<configkey>135</configkey>
<priority>CRITICAL</priority>
<name>comma assumed in initializer</name>
<description>A comma was missing between two initializers. For example: int a[2][2] = { { 1, 2 } { 3, 4 } }; is missing a comma after the first right brace (}).</description>
</rule>
<rule>
<key>136</key>
<configkey>136</configkey>
<priority>CRITICAL</priority>
<name>Illegal macro name</name>
<description>The ANSI standard restricts the use of certain names as macros. defined is on the restricted list.</description>
</rule>
<rule>
<key>137</key>
<configkey>137</configkey>
<priority>CRITICAL</priority>
<name>constant 'Symbol' used twice within switch</name>
<description>The indicated constant was used twice as a case within a switch statement. Currently only enumerated types are checked for repeated occurrence.</description>
</rule>
<rule>
<key>138</key>
<configkey>138</configkey>
<priority>CRITICAL</priority>
<name>Can't add parent 'Symbol' to strong type String; creates loop</name>
<description>An attempt was made to add a strong type parent to a typedef type. The attempt is either explicit (with the -strong option) or implicit with the use of a typedef to a known strong type. This attempt would have caused a loop in the strong parent relationship. Such loops are simply not tolerated.</description>
</rule>
<rule>
<key>139</key>
<configkey>139</configkey>
<priority>CRITICAL</priority>
<name>Can't take sizeof function</name>
<description>There is an attempt to take the sizeof a function.</description>
</rule>
<rule>
<key>140</key>
<configkey>140</configkey>
<priority>CRITICAL</priority>
<name>Type appears after modifier</name>
<description>Microsoft modifiers such as far, _near, __huge, _pascal, etc. etc. modify the declarator to its immediate right. It therefore should not appear before the type. For example, you should write int pascal f(void); rather than pascal int f(void);. Note that const and volatile differ from the Microsoft modifiers. They may appear before or after the type. After reporting the error an attempt is made to process the modifiers as the programmer probably intended.</description>
</rule>
<rule>
<key>141</key>
<configkey>141</configkey>
<priority>CRITICAL</priority>
<name>The following option has too many elements: 'String'</name>
<description>The indicated option (given by 'String') is too big. It most likely consists of an itemized list that has too many items. You should decompose the large option into two or more smaller options that in sum are equivalent to the one large option.</description>
</rule>
<rule>
<key>142</key>
<configkey>142</configkey>
<priority>CRITICAL</priority>
<name>case constant '0' used previously in this switch</name>
<description>case constant '0' used previously in this switch</description>
</rule>
<rule>
<key>143</key>
<configkey>143</configkey>
<priority>CRITICAL</priority>
<name>Erroneous option: String</name>
<description>An option contained information that was inconsistent with itself or with an earlier option. The String provided in the message explains more fully what the problem is.</description>
</rule>
<rule>
<key>144</key>
<configkey>144</configkey>
<priority>CRITICAL</priority>
<name>Non-existent return value for symbol 'Symbol', compare with Location</name>
<description>An attempt was made to use a non-existent return value of the named function (identified by Symbol). It was previously decided that the function did not return a value or was declared with void.</description>
</rule>
<rule>
<key>145</key>
<configkey>145</configkey>
<priority>CRITICAL</priority>
<name>Type expected before operator, void assumed</name>
<description>In a context in which a type is expected no type is found. Rather, an operator '*' or '&' was encountered. The keyword void was assumed to have preceded this operator.</description>
</rule>
<rule>
<key>146</key>
<configkey>146</configkey>
<priority>CRITICAL</priority>
<name>Assuming a binary constant</name>
<description>A constant of the form 0b... was encountered. This was taken to be a binary constant. For example, 0b100 represents the value 4. If your compiler supports binary constants you may suppress this message.</description>
</rule>
<rule>
<key>147</key>
<configkey>147</configkey>
<priority>CRITICAL</priority>
<name>sizeof takes just one argument</name>
<description>An expression of the form sizeof(a,b) was detected. A second argument is non standard and has been used by some compilers to denote an option to the sizeof operator. If your compiler has a use for the second argument then suppress this message.</description>
</rule>
<rule>
<key>148</key>
<configkey>148</configkey>
<priority>CRITICAL</priority>
<name>member 'Symbol' previously declared at Location</name>
<description>The indicated member was previously declared within the same structure or union. Although a redeclaration of a function may appear benign it is just not permitted by the rules of the language. One of the declarations should be removed.</description>
</rule>
<rule>
<key>149</key>
<configkey>149</configkey>
<priority>CRITICAL</priority>
<name>C++ construct 'String' found in C code</name>
<description>An illegal construct was found in C code. It looked as though it might be suitable for C++. The quoted string identifies the construct further.</description>
</rule>
<rule>
<key>150</key>
<configkey>150</configkey>
<priority>CRITICAL</priority>
<name>Token 'String' unexpected String</name>
<description>An unexpected token was encountered. The action taken, if any, is identified by the second message parameter.</description>
</rule>
<rule>
<key>151</key>
<configkey>151</configkey>
<priority>CRITICAL</priority>
<name>Token 'Name' inconsistent with abstract type</name>
<description>In a context in which an abstract type is allowed such as within a cast or after a sizeof, and after starting to parse the abstract type, an identifier was found. For example:
x = (int y) z;</description>
</rule>
<rule>
<key>152</key>
<configkey>152</configkey>
<priority>CRITICAL</priority>
<name>Lob base file 'file name' missing</name>
<description>The indicated file has been specified as the base of lob production via the option -lobbase(). On output, this message is given if the lob base is missing. The situation is correctable by simply producing the missing lob output. This will not be a problem given the appropriate dependencies in the make file. On input, the most likely cause of this message is an out-of-date base file. A hash code within the lob file being read, did not match a similar code already embedded within the base. The input lob file should be considered in error and should be regenerated.</description>
</rule>
<rule>
<key>153</key>
<configkey>153</configkey>
<priority>CRITICAL</priority>
<name>Could not create temporary file</name>
<description>This message is produced when generating a lob output file based upon some lob base file. When the lob file is produced, it is first written to a temporary. The temporary is generated by the C library function tmpnam().</description>
</rule>
<rule>
<key>154</key>
<configkey>154</configkey>
<priority>CRITICAL</priority>
<name>Could not evaluate type 'String', int assumed</name>
<description>String in the message is the second argument to either a printf_code option or a scanf_code option. When used, it was to be evaluated as a type. Unfortunately the type could not be identified.</description>
</rule>
<rule>
<key>155</key>
<configkey>155</configkey>
<priority>CRITICAL</priority>
<name>Ignoring { }'ed sequence within an expression, 0 assumed</name>
<description>Some compilers support what looks like a compound statement as a C/C++ expression. For example to define the absolute value of an integer which guarantees that it will be read only once you may use: #define abs(a) { int b = a; b >= 0 ? b : -b; } The last expression in the list is the result. To syntactically support the construct without running amuck we recognize the sequence and issue this message. If you want to use the facility just suppress the message.</description>
</rule>
<rule>
<key>156</key>
<configkey>156</configkey>
<priority>CRITICAL</priority>
<name>Braced initializer for scalar type 'Name'</name>
<description>An example of an initializer that will draw this complaint is as follows. int s[] = { { 1 } }; After the compiler has seen the first curly it is expecting to see a number (or other numeric expression). Compilers that strictly adhere to the ISO C and C++ Standards will flag this as ill-formed code.
Note that it is legal (but somewhat arcane) to employ a left curly at the top-level when initializing an object of scalar type. For example, the following is well-formed: int i = { 0 }; // OK; initialize scalar i with 0. char *t = { "bar" }; // OK; initialize scalar t with a pointer to // a statically allocated array. Also note: as the example above implies, this message can apply to pointers to arrays of char; it does not apply to arrays.</description>
</rule>
<rule>
<key>157</key>
<configkey>157</configkey>
<priority>CRITICAL</priority>
<name>No data may follow an incomplete array</name>
<description>An incomplete array is allowed within a struct of a C99 or C++ program but no data is allowed to appear after this array. For example: struct A { int x; int a[]; int b; }; This diagnostic is issued when the 'b' is seen.</description>
</rule>
<rule>
<key>158</key>
<configkey>158</configkey>
<priority>CRITICAL</priority>
<name>Assignment to variable 'Symbol' (Location) increases capability</name>
<description>An assignment has been made to a variable that increases capability. A typical capability increase is to remove const protection as in the following example: int *p; const int *q; p = q; // Error 158 If a capability increase is seen in situations other than an assignment or if the variable is not available, Warning 605 is issued. Please see the description of that message for further information concerning capability increase. See also Informational messages 1776 and 1778 in Section 13.8 C++ Informational Messages.</description>
</rule>
<rule>
<key>159</key>
<configkey>159</configkey>
<priority>CRITICAL</priority>
<name>enum following a type is non-standard</name>
<description>Normally two different types are not permitted within the same type specification; this will ordinarily result in Error 104. However, some compilers support 'sized' enumerations wherein a scalar type can precede the enum keyword. E.g. char enum color { red, green, blue }; When the second type is an enum we do not issue a 104 but emit Error 159 instead. By suppressing this message (with -e159) such constructs will be supported.</description>
</rule>
<rule>
<key>160</key>
<configkey>160</configkey>
<priority>CRITICAL</priority>
<name>The sequence '( {' is non standard and is taken to introduce a GNU statement expression</name>
<description>Lint encountered the sequence '( {' in a context where an expression (possibly a sub-expression) is expected. int n = ({ // Error 160 here int y = foo (); int z; if (y > 0) z = y; else z = - y; z; }) // Now n has the last value of z. The primary intention of this message is to alert the user to the non-standard nature of this construct. The typical response is to suppress the message and go on. But a few caveats are in order.
Programmers who intend to work only with C code with the GNU extensions may safely disable this diagnostic but C++ users should think twice. This is partly for the reasons given in GCC's documentation (see the section entitled "Statements and Declarations in Expressions") and partly because the meaning of '( {' will change in G++ when its maintainers implement Initializer Lists (a new core language feature that is expected to appear in the 2010 version of the ISO C++ Standard).</description>
</rule>
<rule>
<key>161</key>
<configkey>161</configkey>
<priority>CRITICAL</priority>
<name>Repeated use of parameter 'Symbol' in parameter list</name>
<description>The name of a function parameter was repeated. For example: void f( int n, int m, int n ) {} will cause this message to be issued. Names of parameters for a given function must all be different.</description>
</rule>
<rule>
<key>165</key>
<configkey>165</configkey>
<priority>CRITICAL</priority>
<name>An emuration cannot be forward-declared (int is assumed)</name>
<description>TODO: An emuration cannot be forward-declared (int is assumed)</description>
</rule>
<rule>
<key>200</key>
<configkey>200</configkey>
<priority>BLOCKER</priority>
<name>Internal Error, subcode=xxxx</name>
<description>Internal error occured - subcode is part of message. This inconsistency should be brought to the attention of Gimpel Software</description>
</rule>
<rule>
<key>301</key>
<configkey>301</configkey>
<priority>BLOCKER</priority>
<name>Stack overflow</name>
<description>There was a stack overflow while processing declarations. Approximately 50 nested declarators were found. For example, if a '/' followed by 50 consecutive '*'s were to introduce a box-like comment and if the '/' were omitted, then this message would be produced.</description>
</rule>
<rule>
<key>302</key>
<configkey>302</configkey>
<priority>BLOCKER</priority>
<name>Exceeded Available Memory</name>
<description>Main memory has been exhausted.</description>
</rule>
<rule>
<key>303</key>
<configkey>303</configkey>
<priority>BLOCKER</priority>
<name>String too long (try +macros)</name>
<description>A single #define definition or macro invocation exceeded an internal limit (of 4096 characters). As the diagnostic indicates the problem can be corrected with an option.</description>
</rule>
<rule>
<key>304</key>
<configkey>304</configkey>
<priority>BLOCKER</priority>
<name>Corrupt object file, code Integer, symbol=String</name>
<description>A PC-lint/FlexeLint object file is apparently corrupted. Please delete the object module and recreate it using the -oo option. The special code identifier number as well as a list of symbol names are optionally suffixed to the message as an aid in diagnosing the problem by technical support.</description>
</rule>
<rule>
<key>305</key>
<configkey>305</configkey>
<priority>BLOCKER</priority>
<name>Unable to open module 'file name'</name>
<description>file name is the name of the file. The named module could not be opened for reading. Perhaps you misspelled the name.</description>
</rule>
<rule>
<key>306</key>
<configkey>306</configkey>
<priority>BLOCKER</priority>
<name>Previously encountered module 'FileName'</name>
<description>FileName is the name of the module. The named module was previously encountered. This is probably a user blunder.</description>
</rule>
<rule>
<key>307</key>
<configkey>307</configkey>
<priority>BLOCKER</priority>
<name>Can't open indirect file 'FileName'</name>
<description>FileName is the name of the indirect file. The named indirect file (ending in .lnt) could not be opened for reading.</description>
</rule>
<rule>
<key>308</key>
<configkey>308</configkey>
<priority>BLOCKER</priority>
<name>Can't write to standard out</name>
<description>stdout was found to equal NULL. This is most unusual.</description>
</rule>
<rule>
<key>309</key>
<configkey>309</configkey>
<priority>BLOCKER</priority>
<name>#error ...</name>
<description>The #error directive was encountered. The ellipsis reflects the original line. Normally processing is terminated at this point. If you set the fce (continue on #error) flag, processing will continue.</description>
</rule>
<rule>
<key>310</key>
<configkey>310</configkey>
<priority>BLOCKER</priority>
<name>Declaration too long: 'String...'</name>
<description>A single declaration was found to be too long for an internal buffer (about 2000 characters). This occurred when attempting to write out the declaration using the -o... option. The first 30 characters of the declaration is given in String. Typically this is caused by a very long struct whose substructures, if any, are untagged. First identify the declaration that is causing the difficulty. If a struct or union, assign a tag to any unnamed substructures or subunion. A typedef can also be used to reduce the size of such a declaration.</description>
</rule>
<rule>
<key>312</key>
<configkey>312</configkey>
<priority>BLOCKER</priority>
<name>Lint Object Module has obsolete or foreign version id: Integer</name>
<description>A lint object module was produced with a prior or different version of PC-lint/FlexeLint. Delete the.lob file and recreate it using your new version of PC-lint/FlexeLint.</description>
</rule>
<rule>
<key>313</key>
<configkey>313</configkey>
<priority>BLOCKER</priority>
<name>Too many files</name>
<description>The number of files that PC-lint/FlexeLint can process has exceeded an internal limit. The FlexeLint user may recompile his system to increase this limit. Look for symbol FSETLEN in custom.h. Currently, the number of files is limited to 4096.</description>
</rule>
<rule>
<key>314</key>
<configkey>314</configkey>
<priority>BLOCKER</priority>
<name>Previously used .lnt file: FileName</name>
<description>The indirect file named was previously encountered. If this was not an accident, you may suppress this message.</description>
</rule>
<rule>
<key>315</key>
<configkey>315</configkey>
<priority>BLOCKER</priority>
<name>Exceeded message limit (see -limit)</name>
<description>The maximum number of messages was exceeded. Normally there is no limit unless one is imposed by the -limit(n) option.</description>
</rule>
<rule>
<key>316</key>
<configkey>316</configkey>
<priority>BLOCKER</priority>
<name>Error while writing to file "file name"</name>
<description>The given file could not be opened for output.</description>
</rule>
<rule>
<key>317</key>
<configkey>317</configkey>
<priority>BLOCKER</priority>
<name>File encoding, String, not currently supported</name>
<description>Lint detected a byte order mark at the beginning of a file which indicated the file is encoded in the given format. As of this writing, the only formats supported to any extent are ASCII and UTF-8 (for which Lint presumes ASCII encoding).</description>
</rule>
<rule>
<key>321</key>
<configkey>321</configkey>
<priority>BLOCKER</priority>
<name>Declaration stack overflow</name>
<description>An overflow occurred in the stack used to contain array, pointer, function or reference modifiers when processing a declarator.</description>
</rule>
<rule>
<key>322</key>
<configkey>322</configkey>
<priority>BLOCKER</priority>
<name>Unable to open include file FileName</name>
<description>FileName is the name of the include file which could not be opened. Directory search is controlled by options: -i +fdi and the INCLUDE environment variable. This is a suppressible fatal message. If option -e322 is used, Error message 7 will kick in. A diagnostic will be issued but processing will continue.</description>
</rule>
<rule>
<key>323</key>
<configkey>323</configkey>
<priority>BLOCKER</priority>
<name>Token String too long</name>
<description>In attempting to save a token for later reuse, a fixed size buffer was exceeded (governed by the size M_TOKEN).</description>
</rule>
<rule>
<key>324</key>
<configkey>324</configkey>
<priority>BLOCKER</priority>
<name>Too many symbols Integer</name>
<description>Too many symbols were encountered. An internal limit was reached.</description>
</rule>
<rule>
<key>325</key>
<configkey>325</configkey>
<priority>BLOCKER</priority>
<name>Cannot re-open file 'file name'</name>
<description>In the case of a large number of nested includes, files in the outer fringe need to be closed before new ones are opened. These outer files then need to be re-opened. An error occurred when attempting to re-open such a file.</description>
</rule>
<rule>
<key>326</key>
<configkey>326</configkey>
<priority>BLOCKER</priority>
<name>String 'String ...' too long, exceeds Integer characters</name>
<description>A string (first 40 characters provided in the message) exceeds some internal limit (provided in the message). There is no antidote to this condition in the form of an option. FlexeLint customers may recompile with a redefinition of either M_STRING (maximum string) or M_NAME (maximum name). To override the definition in custom.h we suggest recompiling with an appropriate -dvar=value option assuming your compiler supports the option.</description>
</rule>
<rule>
<key>328</key>
<configkey>328</configkey>
<priority>BLOCKER</priority>
<name>Bypass header 'Name' follows a different header sequence than in module 'String' which includes File1 where the current module includes File2</name>
<description>This message is issued when a header is #include'd that had previously been designated as bypass and it has been determined that this header follows a different header include sequence than in some other module. The name of the other module is given by the second parameter of this message. In order not to bury the programmer under a ton of header names, we have made an effort to determine the precise point where the two modules went their separate ways. The first include file difference occurred when that other module included the header identified by File1, whereas the current module was attempting to include the header identified by File2. Each Filei is a pair of parameters of the form 'String' (Location) where the location is the point of the #include.
For example: Module x.cpp: #include "alpha.h" #include "delta.h" #include "beta.h" #include "gamma.h"
Module y.cpp: #include "alpha.h" #include "beta.h" #include "gamma.h" When the include of "beta.h" occurs in module y.cpp (and if beta.h has been designated as bypass), there will be a Fatal Error 328 that the header sequence of module 'x.cpp' differs from the current module in that the former module included 'delta.h' at a point where the current module included 'beta.h'.
It was necessary to make this message a fatal error since attempting to bypass headers that do not follow a consistent header sequence is an act of folly. It is possible to continue on after the 328 in hopes of picking up more inconsistencies in other modules. This can be done using the +fce (Continue-on-Error) flag.</description>
</rule>
<rule>
<key>401</key>
<configkey>401</configkey>
<priority>MAJOR</priority>
<name>symbol 'Symbol' not previously declared static at Location</name>
<description>The indicated Symbol declared static was previously declared without the static storage class. This is technically a violation of the ANSI standard. Some compilers will accept this situation without complaint and regard the Symbol as static.</description>
</rule>
<rule>
<key>402</key>
<configkey>402</configkey>
<priority>MAJOR</priority>
<name>static function 'Symbol' (Location) not defined</name>
<description>The named Symbol was declared as a static function in the current module and was referenced but was not defined (in the module).</description>
</rule>
<rule>
<key>403</key>
<configkey>403</configkey>
<priority>MAJOR</priority>
<name>static symbol 'Symbol' has unusual type modifier</name>
<description>Some type modifiers such as _export are inconsistent with the static storage class.</description>
</rule>
<rule>
<key>404</key>
<configkey>404</configkey>
<priority>MAJOR</priority>
<name>struct not completed within file 'FileName'</name>
<description>A struct (or union or enum) definition was started within a header file but was not completed within the same header file.</description>
</rule>
<rule>
<key>405</key>
<configkey>405</configkey>
<priority>MAJOR</priority>
<name>#if not closed off within file 'FileName'</name>
<description>An #if construct was begun within a header file (name given) but was not completed within that header file. Was this intentional?</description>
</rule>
<rule>
<key>406</key>
<configkey>406</configkey>
<priority>MAJOR</priority>
<name>Comment not closed off within file 'FileName'</name>
<description>A comment was begun within a header file (name given) but was not completed within that header file. Was this intentional?</description>
</rule>
<rule>
<key>407</key>
<configkey>407</configkey>
<priority>MAJOR</priority>
<name>Inconsistent use of tag 'Symbol' conflicts with Location</name>
<description>A tag specified as a union, struct or enum was respecified as being one of the other two in the same module. For example: struct tag *p; union tag *q;
will elicit this message.</description>
</rule>
<rule>
<key>408</key>
<configkey>408</configkey>
<priority>MAJOR</priority>
<name>Type mismatch with switch expression</name>
<description>The expression within a case does not agree exactly with the type within the switch expression. For example, an enumerated type is matched against an int.</description>
</rule>
<rule>
<key>409</key>
<configkey>409</configkey>
<priority>MAJOR</priority>
<name>Expecting a pointer or array</name>
<description>An expression of the form i[...] was encountered where i is an integral expression. This could be legitimate depending on the subscript operand. For example, if i is an int and a is an array then i[a] is legitimate but unusual. If this is your coding style, suppress this message.</description>
</rule>
<rule>
<key>410</key>
<configkey>410</configkey>
<priority>MAJOR</priority>
<name>size_t not what was expected from fzl and/or fzu, using 'Type'</name>
<description>This warning is issued if you had previously attempted to set the type of sizeof by use of the options +fzl, -fzl, or -fzu, and a later size_t declaration contradicts the setting. This usually means you are attempting to lint programs for another system using header files for your own system. If this is the case we suggest you create a directory housing header files for that foreign system, alter size_t within that directory, and lint using that directory.</description>
</rule>
<rule>
<key>411</key>
<configkey>411</configkey>
<priority>MAJOR</priority>
<name>ptrdiff_t not what was expected from fdl option, using 'Type'</name>
<description>This warning is issued if you had previously attempted to set the type of pointer differences by use of the fdl option and a later ptrdiff_t declaration contradicts the setting. See suggestion in Error Message 410.</description>
</rule>
<rule>
<key>412</key>
<configkey>412</configkey>
<priority>MAJOR</priority>
<name>Ambiguous format specifier '%X'</name>
<description>The format specifier %X when used with one of the scanf family, is ambiguous. With Microsoft C it means %lx whereas in ANSI C it has the meaning of %x. This ambiguous format specification has no place in any serious C program and should be replaced by one of the above.</description>
</rule>
<rule>
<key>413</key>
<configkey>413</configkey>
<priority>MAJOR</priority>
<name>Likely use of null pointer 'Symbol' in [left/right] argument to operator 'String' Reference</name>
<description>From information gleaned from earlier statements, it appears certain that a null pointer (a pointer whose value is 0) has been used in a context where null pointers are inappropriate. These include: Unary *, pointer increment (++) or decrement, addition of pointer to numeric, and subtraction of two pointers. In the case of binary operators, one of the words 'left' or 'right' is used to designate which operand is null. Symbol identifies the pointer variable that may be null.</description>
</rule>
<rule>
<key>414</key>
<configkey>414</configkey>
<priority>MAJOR</priority>
<name>Possible division by 0</name>
<description>The second argument to either the division operator (/) or the modulus operator (%) may be zero. Information is taken from earlier statements including assignments, initialization and tests.</description>
</rule>
<rule>
<key>415</key>
<configkey>415</configkey>
<priority>MAJOR</priority>
<name>access of out-of-bounds pointer ('Integer' beyond end of data) by operator 'String'</name>
<description>An out-of-bounds pointer was accessed. String designates the operator. The parameter 'Integer' gives some idea how far out of bounds the pointer may be. It is measured in units given by the size of the pointed to object. The value is relative to the last item of good data and therefore should always be greater than zero. For example: int a[10]; a[10] = 0;
results in an overflow message containing the phrase '1 beyond end of data'.</description>
</rule>
<rule>
<key>416</key>
<configkey>416</configkey>
<priority>MAJOR</priority>
<name>creation of out-of-bounds pointer ('Integer' beyond end of data) by operator 'String'</name>
<description>An out-of-bounds pointer was created. See message 415 for a description of the parameters Integer and String. For example: int a[10];
... f( a + 11 );
Here, an illicit pointer value is created and is flagged as such by PC-lint/FlexeLint. Note that the pointer a+10 is not considered by PC-lint/FlexeLint to be the creation of an out-of-bounds pointer. This is because ANSI C explicitly allows pointing just beyond an array. Access through a+10, however, as in *(a+10) or the more familiar a[10], would be considered erroneous but in that case message 415 would be issued.</description>
</rule>
<rule>
<key>417</key>
<configkey>417</configkey>
<priority>MAJOR</priority>
<name>integral constant 'String' has precision Number which is longer than long long int</name>
<description>The longest possible integer is by default 8 bytes (see the +fll flag and then the -sll# option). An integral constant was found to be even larger than such a quantity. For example: 0xFFFF0000FFFF0000F. String is the token in error.</description>
</rule>
<rule>
<key>418</key>
<configkey>418</configkey>
<priority>MAJOR</priority>
<name>Passing null pointer to function 'Symbol', Context Reference</name>
<description>A NULL pointer is being passed to a function identified by Symbol. The argument in question is given by Context. The function is either a library function designed not to receive a NULL pointer or a user function dubbed so via the option -function.</description>
</rule>
<rule>
<key>419</key>
<configkey>419</configkey>
<priority>MAJOR</priority>
<name>Apparent data overrun for function 'Symbol', argument Integer exceeds argument Integer</name>
<description>This message is for data transfer functions such as memcpy, strcpy, fgets, etc. when the size indicated by the first cited argument (or arguments) exceeds the size of the buffer area cited by the second. The message may also be issued for user functions via the -function option.</description>
</rule>
<rule>
<key>420</key>
<configkey>420</configkey>
<priority>MAJOR</priority>
<name>Apparent access beyond array for function 'Symbol', argument Integer exceeds Integer Reference</name>
<description>This message is issued for several library functions (such as fwrite, memcmp, etc.) wherein there is an apparent attempt to access more data than exist. For example, if the length of data specified in the fwrite call exceeds the size of the data specified. The function is specified by Symbol and the arguments are identified by argument number.</description>
</rule>
<rule>
<key>421</key>
<configkey>421</configkey>
<priority>MAJOR</priority>
<name>Caution -- function 'Symbol' is considered dangerous</name>
<description>This message is issued (by default) for the built-in function gets. This function is considered dangerous because there is no mechanism to ensure that the buffer provided as first argument will not overflow. A well known computer virus (technically a worm) was created based on this defect. Through the -function option, the user may designate other functions as dangerous.</description>
</rule>
<rule>
<key>422</key>
<configkey>422</configkey>
<priority>MAJOR</priority>
<name>Passing to function 'Symbol' a negative value (Integer), Context Reference</name>
<description>An integral value that appears to be negative is being passed to a function that is expecting only positive values for a particular argument. The message contains the name of the function (Symbol), the questionable value (Integer) and the argument number (Context). The function may be a standard library function designed to accept only positive values such as malloc or memcpy (third argument), or may have been identified by the user as such through the -function or -sem options.
The negative integral value may in fact be unsigned. Thus: void *malloc( unsigned ); void f() { int n = -1; int *p; p = malloc(n); // Warning 422 p = malloc( (unsigned) n ); // Warning 422 }
will result in the warnings indicated. Note that casting the expression does not inhibit the warning.
There is a slight difference in behavior on 32-bit systems versus 16-bit systems. If long is the same size as int (as in 32-bit systems) the warning is issued based upon the sign bit. If long is larger than an int (as is true on typical 16-bit systems) the warning is issued if the value was a converted negative as in the examples above. It is not issued if an unsigned int has the high-order bit set. This is because it is not unreasonable to malloc more that 32,176 bytes in a 16-bit system.</description>
</rule>
<rule>
<key>423</key>
<configkey>423</configkey>
<priority>MAJOR</priority>
<name>Creation of memory leak in assignment to variable 'Symbol'</name>
<description>An assignment was made to a pointer variable (designated by Symbol) which appeared to already be holding the address of an allocated object which had not been freed. The allocation of memory which is not freed is considered a memory leak.</description>
</rule>
<rule>
<key>424</key>
<configkey>424</configkey>
<priority>MAJOR</priority>
<name>Inappropriate deallocation (Name1) for 'Name2' data.</name>
<description>This message indicates that a deallocation (free(), delete, or delete[]) as specified by String1 is inappropriate for the data being freed. [12, Item 5]
The kind of data (specified by String2) is one or more of: malloc, new, new[], static, auto, member, modified or constant. These have the meanings as described below:
malloc data is data obtained from a call to malloc, calloc or realloc. new and new[] data is data derived from calls to new. static data is either static data within a function or external data. auto data is non-static data in a function. member data is a component of a structure (and hence can't be independently freed). modified data is the result of applying pointer arithmetic to some other pointer. E.g. p = malloc(100); free( p+1 ); // warning
p+1 is considered modified. constant data is the result of casting a constant to a pointer. E.g. int *p = (int *) Ox80002; free(p); // warning</description>
</rule>
<rule>
<key>425</key>
<configkey>425</configkey>
<priority>MAJOR</priority>
<name>'Message' in processing semantic 'String' at token 'String'</name>
<description>This warning is issued when a syntax error is encountered while processing a Semantic option (-sem). The 'Message' depends upon the error. The first 'String' represents the portion of the semantic being processed. The second 'String' denotes the token being scanned when the error is first noticed.</description>
</rule>
<rule>
<key>426</key>
<configkey>426</configkey>
<priority>MAJOR</priority>
<name>Call to function 'Symbol' violates semantic 'String'</name>
<description>This Warning message is issued when a user semantic (as defined by -sem) is violated. 'String' is the subportion of the semantic that was violated. For example: //lint -sem( f, 1n > 10 && 2n > 10 ) void f( int, int ); ... f( 2, 20 );
results in the message:
Call to function 'f(int, int)' violates semantic '(1n>10)'</description>
</rule>
<rule>
<key>427</key>
<configkey>427</configkey>
<priority>MAJOR</priority>
<name>// comment terminates in \</name>
<description>A one-line comment terminates in the back-slash escape sequence. This means that the next line will be absorbed in the comment (by a standards-conforming compiler -- not all compilers do the absorption, so beware). It is much safer to end the line with something other than a back-slash. Simply tacking on a period will do. If you really intend the next line to be a comment, the line should be started with its own double slash (//).</description>
</rule>
<rule>
<key>428</key>
<configkey>428</configkey>
<priority>MAJOR</priority>
<name>negative subscript (Integer) in operator 'String'</name>
<description>A negative integer was added to an array or to a pointer to an allocated area (allocated by malloc, operator new, etc.) This message is not given for pointers whose origin is unknown since a negative subscript is, in general, legal.
The addition could have occurred as part of a subscript operation or as part of a pointer arithmetic operation. The operator is denoted by String. The value of the integer is given by Integer.</description>
</rule>
<rule>
<key>429</key>
<configkey>429</configkey>
<priority>MAJOR</priority>
<name>Custodial pointer 'Symbol' (Location) has not been freed or returned</name>
<description>A pointer of auto storage class was allocated storage which was neither freed nor returned to the caller. This represents a "memory leak". A pointer is considered custodial if it uniquely points to the storage area. It is not considered custodial if it has been copied. Thus: int *p = new int[20]; // p is a custodial pointer int *q = p; // p is no longer custodial p = new int[20]; // p again becomes custodial q = p + 0; // p remains custodial
Here p does not lose its custodial property by merely participating in an arithmetic operation.
A pointer can lose its custodial property by passing the pointer to a function. If the parameter of the function is typed pointer to const or if the function is a library function, that assumption is not made. For example p = malloc(10); strcpy (p, "hello");
Then p still has custody of storage allocated.
It is possible to indicate via semantic options that a function will take custody of a pointer.</description>
</rule>
<rule>
<key>430</key>
<configkey>430</configkey>
<priority>MAJOR</priority>
<name>Character '@', taken to specify variable location, is not standard C/C++</name>
<description>Many compilers for embedded systems have a declaration syntax that specifies a location in place of an initial value for a variable. For example: int x @0x2000;
specifies that variable x is actually location 0x2000. This message is a reminder that this syntax is non-standard (although quite common). If you are using this syntax on purpose, suppress this message.</description>
</rule>
<rule>
<key>431</key>
<configkey>431</configkey>
<priority>MAJOR</priority>
<name>Missing identifier for template parameter number Integer</name>
<description>A template object parameter (as opposed to a type parameter) was not provided with an identifier. Was this an oversight?</description>
</rule>
<rule>
<key>432</key>
<configkey>432</configkey>
<priority>MAJOR</priority>
<name>Suspicious argument to malloc</name>
<description>The following pattern was detected:
malloc( strlen(e+1) )
where e is some expression. This is suspicious because it closely resembles the commonly used pattern:
malloc( strlen(e)+1 )
If you really intended to use the first pattern then an equivalent expression that will not raise this error is:
malloc( strlen(e)-1 )</description>
</rule>
<rule>
<key>433</key>
<configkey>433</configkey>
<priority>MAJOR</priority>
<name>Allocated area not large enough for pointer</name>
<description>An allocation was assigned to a pointer whose reach extends beyond the area that was allocated. This would usually happen only with library allocation routines such as malloc and calloc. For example:
int *p = malloc(1);
This message is also provided for user-declared allocation functions. For example, if a user's own allocation function is provided with the following semantic:
-sem(ouralloc,@P==malloc(1n))
We would report the same message. Please note that it is necessary to designate that the returned area is freshly allocated (ala malloc).
This message is always given in conjunction with the more general Informational Message 826.</description>
</rule>
<rule>
<key>434</key>
<configkey>434</configkey>
<priority>MAJOR</priority>
<name>White space ignored between back-slash and new-line</name>
<description>According to the C and C++ standards, any back-slash followed immediately by a new-line results in the deletion of both characters. For example: #define A \ 34
defines A to be 34. If a blank or tab intervenes between the back-slash and the new-line then according to a strict interpretation of the standard you have defined A to be a back-slash. But this blank is invisible to the naked eye and hence could lead to confusion. Worse, some compilers silently ignore the white-space and the program becomes non-portable.
You should never deliberately place a blank at the end of a line and any such blanks should be removed. If you really need to define a macro with a terminal back-slash you can use a comment as in: #define A \ /* commentary */</description>
</rule>
<rule>
<key>435</key>
<configkey>435</configkey>
<priority>MAJOR</priority>
<name>integral constant 'String' has precision Integer, use +fll to enable long long"</name>
<description>An integer constant was found that had a precision that was too large for a long but would fit within a long long. Yet the +fll flag that enables the long long type was not set.
Check the sizes that you specified for long (-sl#) and for long long (-sll#) and make sure they are correct. Turn on +fll if your compiler supports long long. Otherwise use smaller constants.</description>
</rule>
<rule>
<key>436</key>
<configkey>436</configkey>
<priority>MAJOR</priority>
<name>Apparent preprocessor directive in invocation of macro 'Symbol'</name>
<description>A function like macro was invoked whose arguments extended for multiple lines which included preprocessor statements. This is almost certainly an error brought about by a missing right parenthesis.
By the rules of Standard C the preprocessing directive is absorbed into the macro argument but then will not subsequently get executed. For this reason some compilers treat the apparent preprocessor directive as a directive. This is logical but not portable. It is therefore best to avoid this construct.</description>
</rule>
<rule>
<key>437</key>
<configkey>437</configkey>
<priority>MAJOR</priority>
<name>Passing struct 'Symbol' to ellipsis</name>
<description>A struct is being passed to a function at a parameter position identified by an ellipsis. For example: void g() { struct A { int a; } x; void f( int, ... ); f( 1, x ); ... } This is sufficiently unusual that it is worth pointing out on the likely hood that this is unintended. The situation becomes more severe in the case of a Non-POD struct [10]. In this case the behavior is considered undefined.</description>
</rule>
<rule>
<key>438</key>
<configkey>438</configkey>
<priority>MAJOR</priority>
<name>Last value assigned to variable 'Symbol' not used</name>
<description>A value had been assigned to a variable that was not subsequently used. The message is issued either at a return statement or at the end of a block when the variable goes out of scope. For example, consider the following function: void f( int n ) { int x = 0, y = 1; if( n > 0 ) { int z; z = x + y; if( n > z ) { x = 3; return; } z = 12; } } Here we can report that x was assigned a value that had not been used by the time the return statement had been encountered. We also report that the most recently assigned value to z is unused at the point that z goes out of scope. See message 838 in Section 13.4 C Informational Messages and flags -fiw and -fiz in Sections 2.3.6 Initialization-is-considered-a-Write flag (-fiw) and 2.3.7 Initialization-by-Zero-is-considered-a-Write flag (-fiz) .
This message is suppressed if the variable's address is assigned to a pointer (or, equivalently, the variable is used to directly initialize a reference to non-const).</description>
</rule>
<rule>
<key>440</key>
<configkey>440</configkey>
<priority>MAJOR</priority>
<name>for clause irregularity: variable 'Symbol' tested in 2nd expression does not match 'Symbol' modified in 3rd</name>
<description>A for clause has a suspicious structure. The loop variable, as determined by an examination of the 3rd for clause expression, does not match the variable that is tested in the 2nd for clause expression. For example: for( i = 0; i < 10; j++ ) ... would draw this complaint since the 'i' of the 2nd expression does not match the 'j' of the third expression.</description>
</rule>
<rule>
<key>441</key>
<configkey>441</configkey>
<priority>MAJOR</priority>
<name>for clause irregularity: loop variable 'Symbol' not found in 2nd for expression</name>
<description>The loop variable is determined by an examination of the 3rd for clause expression. A loop variable was found (and its name is given in the message) but it did not appear as one of the accessed symbols of the condition expression (the 2nd for expression). For example: for( p = a; *p; j++ ) ... would draw this complaint since the 2nd expression does not contain the 'j' of the third expression.</description>
</rule>
<rule>
<key>442</key>
<configkey>442</configkey>
<priority>MAJOR</priority>
<name>for clause irregularity: testing direction inconsistent with increment direction</name>
<description>A for clause was encountered that appeared to have a parity problem. For example: for( i = 0; i < 10; i</name><description> ) ... Here the test for i less than 10 seems inconsistent with the 3rd expression of the for clause which decreases the value of i. This same message would be given if i were being increased by the 3rd expression and was being tested for being greater than some value in the 2nd expression.</description>
</rule>
<rule>
<key>443</key>
<configkey>443</configkey>
<priority>MAJOR</priority>
<name>for clause irregularity: variable 'Symbol' initialized in 1st expression does not match 'Symbol' modified in 3rd</name>
<description>A for clause has a suspicious structure. The loop variable, as determined by an examination of the 3rd for clause expression, does not match the variable that is initialized in the 1st expression. For example: for( ii = 0; i < 10; i++ ) ... would draw this complaint since the 'ii' of the 1st expression does not match the 'i' of the third expression.</description>
</rule>
<rule>
<key>444</key>
<configkey>444</configkey>
<priority>MAJOR</priority>
<name>for clause irregularity: pointer 'Symbol' incremented in 3rd expression is tested for NULL in 2nd expression</name>
<description>The following kind of situation has been detected: for( ... ; p == NULL; p++ ) ... A loop variable being incremented or decremented would not normally be checked to see if it is NULL. This is more likely a programmer error.</description>
</rule>
<rule>
<key>445</key>
<configkey>445</configkey>
<priority>MAJOR</priority>
<name>reuse of for loop variable 'Symbol' at 'Location' could cause chaos</name>
<description>A for loop nested within another for loop employed the same loop variable. For example: for( i = 0; i < 100; i++ ) { ... for( i = 0; i < n; i++ ) { ... } }</description>
</rule>
<rule>
<key>446</key>
<configkey>446</configkey>
<priority>MAJOR</priority>
<name>for loop index variable 'Symbol' modified in body of the for loop</name>
<description>A for loop with an identifiable loop index variable was programmed in such a way that the loop body also modifies the index variable. For example: for( i = 0; i < 100; i++ ) { a[i++] = 0; } In general it is better to restrict modifications to for loop index variables to the for clause if at all possible. If this is not possible, you can prefix the for loop with an appropriate lint comment such as: /*lint -e{446} i is modified in the body of the for loop */</description>
</rule>
<rule>
<key>447</key>
<configkey>447</configkey>
<priority>MAJOR</priority>
<name>Extraneous whitespace ignored in include directive for file 'FileName'; opening file 'FileName'</name>
<description>A named file was found to contain either leading or trailing whitespace in the #include directive. While legal, the ISO Standards allow compilers to define how files are specified or the header is identified, including the appearance of whitespace characters immediately after the < or opening " or before the > or closing ". Since filenames tend not to contain leading or trailing whitespace, Lint ignores the (apparently) extraneous characters and processes the directive as though the characters were never given. The use of a -efile option on either String for this message will cause Lint to process #include's with whitespace intact.</description>
</rule>
<rule>
<key>448</key>
<configkey>448</configkey>
<priority>MAJOR</priority>
<name>Likely access of pointer pointing Integer bytes past nul character by operator 'String'</name>
<description>Accessing past the terminating nul character is often an indication of a programmer error. For example: char buf[20]; strcpy( buf, "a" ); char c = buf[4]; // legal but suspect. Although buf has 20 characters, after the strcpy, there would be only two that the programmer would normally be interested in.</description>
</rule>
<rule>
<key>449</key>
<configkey>449</configkey>
<priority>MAJOR</priority>
<name>Pointer variable 'Symbol' previously deallocated</name>
<description>A pointer variable (designated in the message) was freed or deleted in an earlier statement.</description>
</rule>
<rule>
<key>451</key>
<configkey>451</configkey>
<priority>MAJOR</priority>
<name>Header file 'FileName' repeatedly included but does not have a standard include guard</name>
<description>The file named in the message has already been included in the current module. Moreover it has been determined that this header does not have a standard include guard. A standard include guard has the form #ifndef Name #define Name ... #endif with nothing but comments before and after this sequence and nothing but comments between the #ifndef and the #define Name.
This warning may also be accompanied by a 537 (repeated include header). Message 537 is often suppressed because if you are working with include guards, it is not a helpful message. However, the message 451 should be left on in order to check the consistency of the include guards themselves.
See also Elective Note 967 in Section 13.5 C Elective Notes.</description>
</rule>
<rule>
<key>452</key>
<configkey>452</configkey>
<priority>MAJOR</priority>
<name>typedef Symbol 'Symbol' redeclared (TypeDiff) conflicts with Location",</name>
<description>A typedef symbol is being declared to be a different type. This can be legal, especially with multiple modules, but is not good programming practice. It inteferes with program legibility.</description>
</rule>
<rule>
<key>453</key>
<configkey>453</configkey>
<priority>MAJOR</priority>
<name>Function 'Symbol', previously designated pure, String 'Name'</name>
<description>A semantic option designated that the named function, Symbol, is pure (lacking non-local side-effects; see the pure semantic in Section 4. Semantics ). However, an impurity was detected. Such impurities include calling a function through a function pointer, accessing a volatile variable, modifying a static variable or calling a function whose purity PC-lint/FlexeLint cannot verify. String describes which of these reasons apply and Name shows the related variable or function, as appropriate.
Despite the inconsistency reported, the function will continue to be regarded as pure.</description>
</rule>
<rule>
<key>454</key>
<configkey>454</configkey>
<priority>MAJOR</priority>
<name>A thread mutex has been locked but not unlocked</name>
<description>A return point in a function has been reached such that a mutex lock that had been previously set has not been unlocked. E.g., //lint -sem( lock, thread_lock ) void f( int x ) { lock(); if( x < 0 ) return; // Warning 454 ...</description>
</rule>
<rule>
<key>455</key>
<configkey>455</configkey>
<priority>MAJOR</priority>
<name>A thread mutex that had not been locked is being unlocked</name>
<description>A call to an unlock() function was made that was not preceded by a balancing lock(). It is assumed that every mutex lock() function must be balanced by exactly one unlock() function, no more, no less. For example: //lint -sem( lock, thread_lock ) //lint -sem( unlock, thread_unlock ) void f( bool x ) { lock(); /* something */; unlock(); /* something else */ unlock(); // Warning 455 }</description>
</rule>
<rule>
<key>456</key>
<configkey>456</configkey>
<priority>MAJOR</priority>
<name>Two execution paths are being combined with different mutex lock states</name>
<description>It is the purpose of this message to make absolutely certain that every lock has a corresponding unlock in the same unbroken sequence of code in the same function.
Execution paths can be combined at the end of an if statement, switch statement, or the begining of while, for and do statements, a label (target of goto), etc. In all these cases we check to make sure that the mutex lock states are the same. For example: //lint -sem( lock, thread_lock ) void f( bool x ) { if( x ) lock(); // Warning 456 issued here ... It could be argued that if an unlock() call would appear under control of the very same bool x in the example above then all would be well. And if this is your coding style you are free to turn this message off. But errors in mutex locking have such horrible programming consequences as to suggest especially strong measures to assure code correctness. We recommend, for example: //lint -sem( lock, thread_lock ) //lint -sem( unlock, thread_unlock ) void f( bool x ) { if( x ) { lock(); /* something */; unlock(); } else { /* something */ } } If the 'something' that is being executed is sufficently complex, then it can be made into a function.</description>
</rule>
<rule>
<key>457</key>
<configkey>457</configkey>
<priority>MAJOR</priority>
<name>Function 'Symbol1' of thread 'Symbol2' has an unprotected write access to variable 'Symbol3' which is used by function 'Symbol4' of thread 'Symbol5'</name>
<description>A variable (Symbol3) was modified by function (Symbol1) of thread (Symbol2) outside of any recognized mutex lock. It was also accessed by a function (Symbol4) of a second thread (Symbol5). The latter access may or may not have been protected. If unprotected, a second message will be issued with the roles of Symbol1 and Symbol4 interchanged.</description>
</rule>
<rule>
<key>458</key>
<configkey>458</configkey>
<priority>MAJOR</priority>
<name>Function 'Symbol1' of thread 'Symbol2' has an unprotected read access to variable 'Symbol3' which is modified by function 'Symbol4' of thread 'Symbol5'</name>
<description>A variable identified in the message was accessed (non-modifiing) by a function (Symbol1) of thread (Symbol2) outside of any recognized mutex lock. It was also modified by a function (Symbol4) in a second thread (Symbol5). The modification may or may not have been protected. If unprotected, Warning 457 will also be issued.</description>
</rule>
<rule>
<key>459</key>
<configkey>459</configkey>
<priority>MAJOR</priority>
<name>Function 'Symbol' whose address was taken has an unprotected access to variable 'Symbol'</name>
<description>This message is activated only when it appears that the program has more than one thread. See Section 8. Multi-thread Suppport to determine what those conditions might be.
If a function's address is taken, we presume that we are unable to determine statically all the locations from which the function may be called and so we presume that any and all threads can call this function and so the function needs to have protected access to every static variable that it might touch.
There are several remedies to such a message. If multiple threads can indeed access this function, then place a mutex lock in the function. If there already is a mutex lock and we don't recognize it, then set the thread_protected semantic for the function. If only one thread really accesses this function or if the access is guaranteed to be benign, then, after making sure this condition is commented in the code, use the same thread_protected semantic for the function.</description>
</rule>
<rule>
<key>460</key>
<configkey>460</configkey>
<priority>MAJOR</priority>
<name>Thread 'Symbol' has unprotected call to thread unsafe function 'Symbol' which is also called by thread 'Symbol'</name>
<description>The second symbol in the message represents a function that was designated as being thread_unsafe through the -sem option. It was being called in an unprotected region of a thread whose root function is the first symbol in the message. Another thread is also accessing this function and this thread is identified by the third parameter of the message.
Calls to thread unsafe functions need to be protected by mutex locks if they are to be employed by more than one thread.</description>
</rule>
<rule>
<key>461</key>
<configkey>461</configkey>
<priority>MAJOR</priority>
<name>Thread 'Symbol' has unprotected call to function 'Symbol' of group 'Name' while thread 'Symbol' calls function 'Symbol' of the same group</name>
<description>This message is similar to Warning 460 in that a thread (identified in the message as the first Symbol) is making a call on a function (the second Symbol) which had been deduced (through options) as being thread unsafe. Like message 460 there is another thread that is also doing some calling. In this case the other thread is not calling the same function as the first but one which has been placed within the same group (identified by the third parameter) as the first function. See Section 8. Multi-thread Support to obtain further information on thread unsafe function groups and options to determine them.</description>
</rule>
<rule>
<key>462</key>
<configkey>462</configkey>
<priority>MAJOR</priority>
<name>Thread 'Symbol' calling function 'Symbol' is inconsistent with the 'String' semantic</name>
<description>The first Symbol in the message identifies a thread. The second Symbol identifies a function called directly or indirectly by the thread. The String argument specifies a semantic that had been attributed to the functon. It should have one of the following forms:
thread_not thread_not( list ) thread_only( list )
If the second form is given, it means that the thread appears on the list. If the 3rd form is given it means that the thread was not on the list.</description>
</rule>
<rule>
<key>464</key>
<configkey>464</configkey>
<priority>MAJOR</priority>
<name>Buffer argument will be copied into itself</name>
<description>This is issued when we encounter a function argument expression used in such a way that there will be an attempt to copy its contents onto itself. E.g. sprintf( s, "%s", s );</description>
</rule>
<rule>
<key>501</key>
<configkey>501</configkey>
<priority>MAJOR</priority>
<name>Expected signed type</name>
<description>The unary minus operator was applied to an unsigned type. The resulting value is a positive unsigned quantity and may not be what was intended.</description>
</rule>
<rule>
<key>502</key>
<configkey>502</configkey>
<priority>MAJOR</priority>
<name>Expected unsigned type</name>
<description>Unary ~ being a bit operator would more logically be applied to unsigned quantities rather than signed quantities.</description>
</rule>
<rule>
<key>503</key>
<configkey>503</configkey>
<priority>MAJOR</priority>
<name>Boolean argument to relational</name>
<description>Normally a relational would not have a Boolean as argument. An example of this is a < b < c which is technically legal but does not produce the same result as the mathematical expression which it resembles.</description>
</rule>
<rule>
<key>504</key>
<configkey>504</configkey>
<priority>MAJOR</priority>
<name>Unusual shift operation (String)</name>
<description>Either the quantity being shifted or the amount by which a quantity is to be shifted was derived in an unusual way such as with a bit-wise logical operator, a negation, or with an unparenthesized expression. If the shift value is a compound expression that is not parenthesized, parenthesize it.</description>
</rule>
<rule>
<key>505</key>
<configkey>505</configkey>
<priority>MAJOR</priority>
<name>Redundant left argument to comma</name>
<description>The left argument to the comma operator had no side effects in its top-most operator and hence is redundant.</description>
</rule>
<rule>
<key>506</key>
<configkey>506</configkey>
<priority>MAJOR</priority>
<name>Constant value Boolean</name>
<description>A Boolean, i.e., a quantity found in a context that requires a Boolean such as an argument to && or || or an if() or while() clause or ! was found to be a constant and hence will evaluate the same way each time.</description>
</rule>
<rule>
<key>507</key>
<configkey>507</configkey>
<priority>MAJOR</priority>
<name>Size incompatibility</name>
<description>A cast was made to an integral quantity from a pointer and according to other information given or implied it would not fit. For example a cast to an unsigned int was specified and information provided by the options indicate that a pointer is are larger than an int.</description>
</rule>
<rule>
<key>508</key>
<configkey>508</configkey>
<priority>MAJOR</priority>
<name>extern used with definition</name>
<description>A function definition was accompanied with an extern storage class. extern is normally used with declarations rather than with definitions. At best the extern is redundant. At worst you may trip up a compiler.</description>
</rule>
<rule>
<key>509</key>
<configkey>509</configkey>
<priority>MAJOR</priority>
<name>extern used with definition</name>
<description>A data object was defined with a storage class of extern. This is technically legal in ANSI and you may want to suppress this message. However, it can easily trip up a compiler and so the practice is not recommended at this time.</description>
</rule>
<rule>
<key>511</key>
<configkey>511</configkey>
<priority>MAJOR</priority>
<name>Size incompatibility</name>
<description>A cast was made from an integral type to a pointer and the size of the quantity was too large to fit into the pointer. For example if a long is cast to a pointer and if options indicate that a long ise larger than a pointer, this warning would be reported.</description>
</rule>
<rule>
<key>512</key>
<configkey>512</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' previously used as static (Location)</name>
<description>The Symbol name given is a function name that was declared as static in some other module (the location of that declaration is provided). The use of a name as static in one module and external in another module is legal but suspect.</description>
</rule>
<rule>
<key>514</key>
<configkey>514</configkey>
<priority>MAJOR</priority>
<name>Unusual use of a Boolean</name>
<description>An argument to an arithmetic operator (+ - / * %) or a bit-wise logical operator (| & ^) was a Boolean. This can often happen by accident as in:
if( flags & 4 == 0 )
where the ==, having higher precedence than &, is done first (to the puzzlement of the programmer).</description>
</rule>
<rule>
<key>515</key>
<configkey>515</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' has arg. count conflict (Integer vs. Integer) with Location</name>
<description>An inconsistency was found in the number of actual arguments provided in a function call and either the number of formal parameters in its definition or the number of actual arguments in some other function call. See the +fva option to selectively suppress this message.</description>
</rule>
<rule>
<key>516</key>
<configkey>516</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' has arg. type conflict (no. Integer -- TypeDiff) with Location</name>
<description>An inconsistency was found in the type of an actual argument in a function call with either the type of the corresponding formal parameter in the function definition or the type of an actual argument in another call to the same function or with the type specified for the argument in the function's prototype. The call is not made in the presence of a prototype. See options -ean, -eau, -eas and -eai for selective suppression of some kinds of type differences. If the conflict involves types char or short then you may want to consider using the +fxc or +fxs option.</description>
</rule>
<rule>
<key>517</key>
<configkey>517</configkey>
<priority>MAJOR</priority>
<name>defined not K&R</name>
<description>The defined function (not a K&R construct) was employed and the K&R preprocessor flag (+fkp) was set. Either do not set the flag or do not use defined.</description>
</rule>
<rule>
<key>518</key>
<configkey>518</configkey>
<priority>MAJOR</priority>
<name>Expected '('</name>
<description>sizeof type is not strict C. sizeof(type) or sizeof expression are both permissible.</description>
</rule>
<rule>
<key>519</key>
<configkey>519</configkey>
<priority>MAJOR</priority>
<name>Size incompatibility</name>
<description>An attempt was made to cast a pointer to a pointer of unequal size. This could occur for example in a P model where pointers to functions require 4 bytes whereas pointers to data require only 2. This error message can be circumvented by first casting the pointer to an integral quantity (int or long) before casting to a pointer.</description>
</rule>
<rule>
<key>520</key>
<configkey>520</configkey>
<priority>MAJOR</priority>
<name>Highest operator or function lacks side-effects</name>
<description>The first expression of a for clause should either be one of the privileged operators: assignment, increment, decrement or call to an impure function or one modifying its argument(s).</description>
</rule>
<rule>
<key>521</key>
<configkey>521</configkey>
<priority>MAJOR</priority>
<name>Highest operator or function lacks side-effects</name>
<description>The third expression of a for clause should either be one of the privileged operators: assignment, increment, decrement or call to an impure function or one modifying its argument(s).</description>
</rule>
<rule>
<key>522</key>
<configkey>522</configkey>
<priority>MAJOR</priority>
<name>Highest operator or function lacks side-effects</name>
<description>If a statement consists only of an expression, it should either be one of the privileged operators: assignment, increment, decrement or call to an impure function or one modifying its argument(s). For example if operator * is the built-in operator, the statement *p++; draws this message but p++; does not. This is because the highest operator is '*' which has no side effects.
The definition of pure and impure functions and function calls which have side effects are given in the discussion of the pure semantic in section 4. Semantics</description>
</rule>
<rule>
<key>524</key>
<configkey>524</configkey>
<priority>MAJOR</priority>
<name>Loss of precision (Context) (Type to Type)</name>
<description>There is a possible loss of a fraction in converting from a float to an integral quantity. Use of a cast will suppress this message.</description>
</rule>
<rule>
<key>525</key>
<configkey>525</configkey>
<priority>MAJOR</priority>
<name>Negative indentation from Location</name>
<description>The current line was found to be negatively indented (i.e., not indented as much) from the indicated line. The latter corresponds to a clause introducing a control structure and statements and other control clauses and braces within its scope are expected to have no less indentation. If tabs within your program are other than 8 blanks you should use the -t option.</description>
</rule>
<rule>
<key>526</key>
<configkey>526</configkey>
<priority>MAJOR</priority>
<name>'Symbol' (Location) not defined</name>
<description>The named external was referenced but not defined and did not appear declared in any library header file nor did it appear in a Library Module. This message is suppressed for unit checkout (-u option). Please note that a declaration, even one bearing prototype information is not a definition. See the glossary at the beginning of this chapter. If the Symbol is a library symbol, make sure that it is declared in a header file that you're including. Also make sure that the header file is regarded by PC-lint/FlexeLint as a Library Header file. Alternatively, the symbol may be declared in a Library Module.</description>
</rule>
<rule>
<key>527</key>
<configkey>527</configkey>
<priority>MAJOR</priority>
<name>Unreachable code at token Symbol</name>
<description>A portion of the program cannot be reached.</description>
</rule>
<rule>
<key>528</key>
<configkey>528</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' (Location) not referenced</name>
<description>The named static variable or static function was not referenced in the module after having been declared.</description>
</rule>
<rule>
<key>529</key>
<configkey>529</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' (Location) not subsequently referenced</name>
<description>The named variable was declared but not referenced in a function.</description>
</rule>
<rule>
<key>530</key>
<configkey>530</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' (Location) not initialized</name>
<description>An auto variable was used before it was initialized.</description>
</rule>
<rule>
<key>531</key>
<configkey>531</configkey>
<priority>MAJOR</priority>
<name>Field size too large for 'Symbol'</name>
<description>The size given for a bit field of a structure exceeds the size of an int.</description>
</rule>
<rule>
<key>532</key>
<configkey>532</configkey>
<priority>MAJOR</priority>
<name>Return mode of function 'Symbol' inconsistent with Location</name>
<description>A declaration (or a definition) of a function implies a different return mode than a previous statement. (The return mode of a function has to do with whether the function does, or does not, return a value). A return mode is determined from a declaration by seeing if the function returns void or, optionally, by observing whether an explicit type is given. See the fdr flag for a further explanation of this. See also the fvr and fvo flags.</description>
</rule>
<rule>
<key>533</key>
<configkey>533</configkey>
<priority>MAJOR</priority>
<name>function 'Symbol' should (not) return a value (see Location)</name>
<description>A return statement within a function (or lack of a return at the end of the function) implies a different return mode than a previous statement at Location (The return mode of a function has to do with whether the function does, or does not, return a value.)</description>
</rule>
<rule>
<key>534</key>
<configkey>534</configkey>
<priority>MAJOR</priority>
<name>Ignoring return value of function 'Symbol' (compare with Location)</name>
<description>A function that returns a value is called just for side effects as, for example, in a statement by itself or the left-hand side of a comma operator. Try: (void) function(); to call a function and ignore its return value. See also the fvr, fvo and fdr flags.</description>
</rule>
<rule>
<key>537</key>
<configkey>537</configkey>
<priority>MAJOR</priority>
<name>Repeated include file 'FileName'</name>
<description>The file whose inclusion within a module is being requested has already been included in this compilation. The file is processed normally even if the message is given. If it is your standard practice to repeat included files then simply suppress this message.</description>
</rule>
<rule>
<key>538</key>
<configkey>538</configkey>
<priority>MAJOR</priority>
<name>Excessive size</name>
<description>The size of an array equals or exceeds 64K bytes.</description>
</rule>
<rule>
<key>539</key>
<configkey>539</configkey>
<priority>MAJOR</priority>
<name>Did not expect positive indentation from Location</name>
<description>The current line was found to be positively indented from a clause that did not control the line in question. For example: if( n > 0 ) x = 3; y = 4;
will result in this warning being issued for y = 4;. The Location cited will be that of the if clause.</description>
</rule>
<rule>
<key>540</key>
<configkey>540</configkey>
<priority>MAJOR</priority>
<name>Excessive size</name>
<description>A string initializer required more space than what was allocated.</description>
</rule>
<rule>
<key>541</key>
<configkey>541</configkey>
<priority>MAJOR</priority>
<name>Excessive size</name>
<description>The size of a character constant specified with \xddd or \xhhh equalled or exceeded 2**b where b is the number of bits in a byte (established by the -sb option). The default is -sb8.</description>
</rule>
<rule>
<key>542</key>
<configkey>542</configkey>
<priority>MAJOR</priority>
<name>Excessive size for bit field</name>
<description>An attempt was made to assign a value into a bit field that appears to be too small. The value to be assigned is either another bit field larger than the target, or a numeric value that is simply too large. You may cast the value to the generic unsigned type to suppress the error.
You may get this message unexpectedly if the base of the bit field is an int. For example: struct { int b : 1 } s; s.b = 1; /* Warning - - requires 0 or -1 */
The solution in this case is to use 'unsigned' rather than 'int' in the declaration of b.</description>
</rule>
<rule>
<key>544</key>
<configkey>544</configkey>
<priority>MAJOR</priority>
<name>endif or else not followed by EOL</name>
<description>The preprocessor directive #endif should be followed by an end-of-line. Some compilers specifically allow commentary to follow the #endif. If you are following that convention simply turn this error message off.</description>
</rule>
<rule>
<key>545</key>
<configkey>545</configkey>
<priority>MAJOR</priority>
<name>Suspicious use of &</name>
<description>An attempt was made to take the address of an array name. At one time such an expression was officially illegal (K&R C [1]), was not consistently implemented, and was, therefore, suspect. However, the expression is legal in ANSI C and designates a pointer to an array. For example, given
int a[10]; int (*p) [10];
Then a and &a, as pointers, both represent the same bit pattern, but whereas a is a pointer to int, &a is a pointer to array 10 of int. Of the two only &a may be assigned to p without complaint. If you are using the & operator in this way, we recommend that you disable this message.</description>
</rule>
<rule>
<key>546</key>
<configkey>546</configkey>
<priority>MAJOR</priority>
<name>Suspicious use of &</name>
<description>An attempt was made to take the address of a function name. Since names of functions by themselves are promoted to address, the use of the & is redundant and could be erroneous.</description>
</rule>
<rule>
<key>547</key>
<configkey>547</configkey>
<priority>MAJOR</priority>
<name>Redefinition of symbol 'Symbol' conflicts with Location</name>
<description>The indicated symbol had previously been defined (vis #define)to some other value.</description>
</rule>
<rule>
<key>548</key>
<configkey>548</configkey>
<priority>MAJOR</priority>
<name>else expected</name>
<description>A construct of the form if(e); was found which was not followed by an else. This is almost certainly an unwanted semi-colon as it inhibits the if from having any effect.</description>
</rule>
<rule>
<key>549</key>
<configkey>549</configkey>
<priority>MAJOR</priority>
<name>Suspicious cast</name>
<description>A cast was made from a pointer to some enumerated type or from an enumerated type to a pointer. This is probably an error. Check your code and if this is not an error, then cast the item to an intermediate form (such as an int or a long) before making the final cast.</description>
</rule>
<rule>
<key>550</key>
<configkey>550</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' (Location) not accessed</name>
<description>A variable (local to some function) was not accessed. This means that the value of a variable was never used. Perhaps the variable was assigned a value but was never used. Note that a variable's value is not considered accessed by autoincrementing or autodecrementing unless the autoincrement/decrement appears within a larger expression which uses the resulting value. The same applies to a construct of the form: var += expression. If an address of a variable is taken, its value is assumed to be accessed. An array, struct or union is considered accessed if any portion thereof is accessed.</description>
</rule>
<rule>
<key>551</key>
<configkey>551</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' (Location) not accessed</name>
<description>A variable (declared static at the module level) was not accessed though the variable was referenced. See the explanation under message 550 (above) for a description of "access".</description>
</rule>
<rule>
<key>552</key>
<configkey>552</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' (Location) not accessed</name>
<description>An external variable was not accessed though the variable was referenced. See the explanation under message 550 above for a description of "access".</description>
</rule>
<rule>
<key>553</key>
<configkey>553</configkey>
<priority>MAJOR</priority>
<name>Undefined preprocessor variable 'Name', assumed 0</name>
<description>The indicated variable had not previously been defined within a #define statement and yet it is being used in a preprocessor condition of the form #if or #elif. Conventionally all variables in preprocessor expressions should be pre-defined. The value of the variable is assumed to be 0.</description>
</rule>
<rule>
<key>555</key>
<configkey>555</configkey>
<priority>MAJOR</priority>
<name>#elif not K&R</name>
<description>The #elif directive was used and the K&R preprocessor flag (+fkp) was set. Either do not set the flag or do not use #elif.</description>
</rule>
<rule>
<key>556</key>
<configkey>556</configkey>
<priority>MAJOR</priority>
<name>indented #</name>
<description>A preprocessor directive appeared indented within a line and the K&R preprocessor flag (+fkp) was set. Either do not set the flag or do not indent the #.</description>
</rule>
<rule>
<key>557</key>
<configkey>557</configkey>
<priority>MAJOR</priority>
<name>unrecognized format</name>
<description>The format string supplied to printf, fprintf, sprintf, scanf, fscanf, or sscanf was not recognized. It is neither a standard format nor is it a user-defined format (see printf_code and scanf_code).</description>
</rule>
<rule>
<key>558</key>
<configkey>558</configkey>
<priority>MAJOR</priority>
<name>Too few arguments for format (Integer missing)</name>
<description>The number of arguments supplied to printf, sprintf, fprintf, scanf, fscanf or sscanf was inconsistent with the number expected as a result of analyzing the format string.</description>
</rule>
<rule>
<key>559</key>
<configkey>559</configkey>
<priority>MAJOR</priority>
<name>size of argument number Integer inconsistent with format</name>
<description>The given argument (to printf, sprintf, or fprintf) was inconsistent with that which was anticipated as the result of analyzing the format string. Argument counts begin at 1 and include file, string and format specifications. For example,
sprintf( buffer, "%f", 371 )
will show an error in argument number 3 because constant 371 is not floating point.</description>
</rule>
<rule>
<key>560</key>
<configkey>560</configkey>
<priority>MAJOR</priority>
<name>argument no. Integer should be a pointer</name>
<description>The given argument (to one of the scanf or printf family of functions) should be a pointer. For the scanf family, all arguments corresponding to a format specification should be pointers to areas that are to be modified (receive the results of scanning). For the printf family, arguments corresponding to %s or %n also need to be pointers.
Argument counts begin at 1 and include file, string and format specifications. For example
scanf( "%f", 3.5 )
will generate the message that argument no. 2 should be a pointer.</description>
</rule>
<rule>
<key>561</key>
<configkey>561</configkey>
<priority>MAJOR</priority>
<name>(arg. no. Integer) indirect object inconsistent with format</name>
<description>The given argument (to scanf, sscanf, or fscanf) was a pointer to an object that was inconsistent with that which was anticipated as the result of analyzing the format string. Argument counts begin at 1 and include file, string and format specifications. For example if n is declared as int then:
scanf( "%c", &n )
will elicit this message for argument number 2.</description>
</rule>
<rule>
<key>562</key>
<configkey>562</configkey>
<priority>MAJOR</priority>
<name>Ellipsis (...) assumed</name>
<description>Within a function prototype a comma was immediately followed by a right parenthesis. This is taken by some compilers to be equivalent to an ellipsis (three dots) and this is what is assumed by PC-lint/FlexeLint. If your compiler does not accept the ellipsis but makes this assumption, then you should suppress this message.</description>
</rule>
<rule>
<key>563</key>
<configkey>563</configkey>
<priority>MAJOR</priority>
<name>Label 'Symbol' (Location) not referenced</name>
<description>The Symbol at the cited Location appeared as a label but there was no statement that referenced this label.</description>
</rule>
<rule>
<key>564</key>
<configkey>564</configkey>
<priority>MAJOR</priority>
<name>variable 'Symbol' depends on order of evaluation</name>
<description>The named variable was both modified and accessed in the same expression in such a way that the result depends on whether the order of evaluation is left-to-right or right-to-left. One such example is: n + n++ since there is no guarantee that the first access to n occurs before the increment of n. Other, more typical cases, are given in the manual. Volatile variables are also checked for repeated use in an expression.</description>
</rule>
<rule>
<key>565</key>
<configkey>565</configkey>
<priority>MAJOR</priority>
<name>tag 'Symbol' not previously seen, assumed file-level scope</name>
<description>The named tag appeared in a prototype or in an inner block and was not previously seen in an outer (file-level) scope. The ANSI standard is dubious as to how this tag could link up with any other tag. For most compilers this is not an error and you can safely suppress the message. On the other hand, to be strictly in accord with ANSI C you may place a small stub of a declaration earlier in the program. For example:
struct name;
is sufficient to reserve a place for name in the symbol table at the appropriate level.</description>
</rule>
<rule>
<key>566</key>
<configkey>566</configkey>
<priority>MAJOR</priority>
<name>Inconsistent or redundant format char 'Char'</name>
<description>This message is given for format specifiers within formats for the printf/scanf family of functions. The indicated character Char found in a format specifier was inconsistent or redundant with an earlier character found in the same format specifier. For example a format containing "%ls" will yield this error with the character 's' indicated. This is because the length modifier is designed to be used with integral or float conversions and has no meaning with the string conversion. Such characters are normally ignored by compilers.</description>
</rule>
<rule>
<key>567</key>
<configkey>567</configkey>
<priority>MAJOR</priority>
<name>Expected a numeric field before char 'Char'</name>
<description>This message is given for format specifiers within formats for the printf/scanf family of functions. A numeric field or asterisk was expected at a particular point in the scanning of the format. For example: %-d requests left justification of a decimal integer within a format field. But since no field width is given, the request is meaningless.</description>
</rule>
<rule>
<key>568</key>
<configkey>568</configkey>
<priority>MAJOR</priority>
<name>nonnegative quantity is never less than zero.</name>
<description>Comparisons of the form:
u >= 0 0 <= u u < 0 0 > u
are suspicious if u is an unsigned quantity or a quantity judged to be never less then 0. See also message 775.</description>
</rule>
<rule>
<key>569</key>
<configkey>569</configkey>
<priority>MAJOR</priority>
<name>Loss of information (Context) (Integer bits to Integer bits)</name>
<description>An assignment (or implied assignment, see Context) was made from a constant to an integral variable that is not large enough to hold the constant. Examples include placing a hex constant whose bit requirement is such as to require an unsigned int into a variable typed as int. The number of bits given does not count the sign bit.</description>
</rule>
<rule>
<key>570</key>
<configkey>570</configkey>
<priority>MAJOR</priority>
<name>Loss of sign (Context) (Type to Type)</name>
<description>An assignment (or implied assignment, see Context) is being made from a negative constant into an unsigned quantity. Casting the constant to unsigned will remove the diagnostic but is this what you want. If you are assigning all ones to an unsigned, remember that ~0 represents all ones and is more portable than -1.</description>
</rule>
<rule>
<key>571</key>
<configkey>571</configkey>
<priority>MAJOR</priority>
<name>Suspicious Cast</name>
<description>Usually this warning is issued for casts of the form:
(unsigned) ch
where ch is declared as char and char is signed. Although the cast may appear to prevent sign extension of ch, it does not. Following the normal promotion rules of C, ch is first converted to int which extends the sign and only then is the quantity cast to unsigned. To suppress sign extension you may use:
(unsigned char) ch
Otherwise, if sign extension is what you want and you just want to suppress the warning in this instance you may use:
(unsigned) (int) ch
Although these examples have been given in terms of casting a char they will also be given whenever this cast is made upon a signed quantity whose size is less than the casted type. Examples include signed bit fields (a possibility in the new standard), expressions involving char, and expressions involving short when this type is smaller than int or a direct cast of an int to an unsigned long (if int's is smaller than long). This message is not issued for constants or for expressions involving bit operations.</description>
</rule>
<rule>
<key>572</key>
<configkey>572</configkey>
<priority>MAJOR</priority>
<name>Excessive shift value (precision Integer shifted right by Integer)</name>
<description>A quantity is being shifted to the right whose precision is equal to or smaller than the shifted value. For example,
ch >> 10
will elicit this message if ch is typed char and where char is less than 10 bits wide (the usual case). To suppress the message you may cast the shifted quantity to a type whose length is at least the length of the shift value.</description>
</rule>
<rule>
<key>573</key>
<configkey>573</configkey>
<priority>MAJOR</priority>
<name>Signed-unsigned mix with divide</name>
<description>one of the operands to / or % was signed and the other unsigned; moreover the signed quantity could be negative. For example:
u / n
where u is unsigned and n is signed will elicit this message whereas:
u / 4
will not, even though 4 is nominally an int. It is not a good idea to mix unsigned quantities with signed quantities in any case (a 737 will also be issued) but, with division, a negative value can create havoc. For example, the innocent looking:
n = n / u
will, if n is -2 and u is 2, not assign -1 to n but will assign some very large value.
To resolve this problem, either cast the integer to unsigned if you know it can never be less than zero or cast the unsigned to an integer if you know it can never exceed the maximum integer.</description>
</rule>
<rule>
<key>574</key>
<configkey>574</configkey>
<priority>MAJOR</priority>
<name>Signed-unsigned mix with relational</name>
<description>The four relational operators are: > >= < <=
One of the operands to a relational operator was signed and the other unsigned; also, the signed quantity could be negative. For example:
if( u > n ) ...
where u is unsigned and n is signed will elicit this message whereas:
if( u > 12 ) ...
will not (even though 12 is officially an int it is obvious that it is not negative). It is not a good idea to mix unsigned quantities with signed quantities in any case (a 737 will also be issued) but, with the four relationals, a negative value can produce obscure results. For example, if the conditional:
if( n < 0 ) ...
is true then the similar appearing:
u = 0; if( n < u ) ...
is false because the promotion to unsigned makes n very large.
To resolve this problem, either cast the integer to unsigned if you know it can never be less than zero or cast the unsigned to an int if you know it can never exceed the maximum int.</description>
</rule>
<rule>
<key>575</key>
<configkey>575</configkey>
<priority>MAJOR</priority>
<name>enumeration constant exceeds range for integers</name>
<description>For many compilers the value of an enumeration constant is limited to those values that can fit within a signed or unsigned int.</description>
</rule>
<rule>
<key>577</key>
<configkey>577</configkey>
<priority>MAJOR</priority>
<name>Mixed memory model (option 'String')</name>
<description>The indicated option requested a change to the memory model after part or all of another module was processed. The memory model option should be specified before any module is processed. The most common cause of this error is specifying the memory model after having specified the standard library. This would be a natural error to make if the standard library file were specified via a LINT environment variable.</description>
</rule>
<rule>
<key>578</key>
<configkey>578</configkey>
<priority>MAJOR</priority>
<name>Declaration of symbol 'Symbol' hides symbol 'Symbol' (Location)</name>
<description>A local symbol has the identical name as a global symbol ( or possibly another local symbol). This could be dangerous. Was this deliberate? It is usually best to rename the local symbol.</description>
</rule>
<rule>
<key>579</key>
<configkey>579</configkey>
<priority>MAJOR</priority>
<name>parameter preceding ellipsis has invalid type</name>
<description>When an ellipsis is used, the type preceding the ellipsis should not be a type that would undergo a default promotion such as char, short or float. The reason is that many compilers' variable argument schemes (using stdarg.h) will break down.</description>
</rule>
<rule>
<key>580</key>
<configkey>580</configkey>
<priority>MAJOR</priority>
<name>Redeclaration of function 'Symbol' (hiding Location) causes loss of prototype</name>
<description>A declaration of a function within a block hides a declaration in an outer scope in such a way that the inner declaration has no prototype and the outer declaration does. A common misconception is that the resulting declaration is a composite of both declarations but this is only the case when the declarations are in the same scope not within nested scopes. If you don't care about prototypes you may suppress this message. You will still receive other type-difference warnings.</description>
</rule>
<rule>
<key>581</key>
<configkey>581</configkey>
<priority>MAJOR</priority>
<name>Option 'String' is obsolete and should no longer be used</name>
<description>This message is issued whenever we encounter an option that appears to do more harm than good. 'String' is the option in question.</description>
</rule>
<rule>
<key>582</key>
<configkey>582</configkey>
<priority>MAJOR</priority>
<name>esym (or emacro) name 'String' should not contain '('</name>
<description>The name provided to esym should not contain a (. For example, to suppress message 534 when calling f(int) use the option -esym(534,f) even if f is overloaded.</description>
</rule>
<rule>
<key>583</key>
<configkey>583</configkey>
<priority>MAJOR</priority>
<name>Comparing type 'Type' with EOF</name>
<description>The message is issued when some form of character is compared against the EOF macro. EOF is normally defined to be -1. For example: while( (ch = getchar()) != EOF ) ... If ch is defined to be an int all is well. If however it is defined to be some form of char, then trouble might ensue. If ch is an unsigned char then it can never equal EOF. If ch is a signed char then you could get a premature termination because some data character happened to be all ones.
Note that getchar returns an int. The reason it returns an int and not a char is because it must be capable of returning 257 different values (256 different characters plus EOF, assuming an 8-bit character). Once this value is assigned to a char only 256 values are then possible -- a clear loss of information.</description>
</rule>
<rule>
<key>584</key>
<configkey>584</configkey>
<priority>MAJOR</priority>
<name>Trigraph sequence (??Char) detected</name>
<description>This message is issued whenever a trigraph sequence is detected and the trigraph processing has been turned off (with a -ftg). If this is not within a string (or character) constant then the trigraph sequence is ignored. This is useful if your compiler does not process trigraph sequences and you want linting to mirror compilation. Outside of a string we issue the Warning but we do translate the sequence since it cannot make syntactic sense in its raw state.</description>
</rule>
<rule>
<key>585</key>
<configkey>585</configkey>
<priority>MAJOR</priority>
<name>The sequence (??Char) is not a valid Trigraph sequence</name>
<description>This warning is issued whenever a pair of '?' characters is seen within a string (or character) constant but that pair is not followed by a character which would make the triple a valid Trigraph sequence. Did the programmer intend this to be a Trigraph sequence and merely err? Even if no Trigraph were intended, it can easily be mistaken by the reader of the code to be a Trigraph. Moreover, what assurances do we have that in the future the invalid Trigraph might not become a valid Trigraph and change the meaning of the string? To protect yourself from such an event you may place a backslash between the '?' characters. Alternatively you may use concatenation of string constants. For example: pattern = "(???) ???-????"; // warning 585 pattern = "(?\?\?) ?\?\?-?\?\?\?"; // no warning #define Q "?" pattern = "(" Q Q Q ") " Q Q Q "-" Q Q Q Q // no warning</description>
</rule>
<rule>
<key>586</key>
<configkey>586</configkey>
<priority>MAJOR</priority>
<name>String 'Name' is deprecated. String</name>
<description>The Name has been deprecated by some use of the deprecate option. See Section 2.5.7 -deprecate. The first String is one of the allowed categories of deprecation. The trailing String is part of the deprecate option and should explain why the facility has been deprecated.</description>
</rule>
<rule>
<key>587</key>
<configkey>587</configkey>
<priority>MAJOR</priority>
<name>Predicate 'String' can be pre-determined and always evaluates to String</name>
<description>The predicate, identified by the first String, (one of greater than, greater than or equal, less than, less than or equal, equal, or not equal), cannot possibly be other than what is indicated by the second String parameter. For example: unsigned u; ... if( (u & 0x10) == 0x11 ) ... would be greeted with the message that '==' always evaluates to 'False'.</description>
</rule>
<rule>
<key>588</key>
<configkey>588</configkey>
<priority>MAJOR</priority>
<name>Predicate 'String' will always evaluate to String unless an overflow occurs</name>
<description>The predicate, identified by the first String, cannot possibly be other than what is indicated by the second String parameter unless an overflow occurred. For example: unsigned u; ... if( (u + 2) != 1 ) ... would be greeted with the message that '!=' always evaluates to 'True'. See also Message 587.</description>
</rule>
<rule>
<key>589</key>
<configkey>589</configkey>
<priority>MAJOR</priority>
<name>Predicate 'String' will always evaluate to String assuming standard division semantics</name>
<description>The predicate, identified by the first String parameter, cannot possibly be other than what is indicated by the second String parameter assuming standard signed integer division semantics. For example: int n; ... if( n % 2 == 2 ) ... would be greeted with the message that '==' always evaluates to 'False'.
By standard integer division semantics we mean truncation toward zero so that, for example, -1/4 has quotient 0 and remainder -1 and not quotient -1, remainder 3. Although the current C standard [4] has endorsed this, the current C++ standard [10] regards integer division involving negative numbers to be 'implementation defined'.
See also Message 587.</description>
</rule>
<rule>
<key>590</key>
<configkey>590</configkey>
<priority>MAJOR</priority>
<name>Predicate 'String' will always evaluate to String assuming standard shift semantics</name>
<description>The predicate, identified by the first String parameter, cannot possibly be other than what is indicated by the second String parameter assuming standard signed integer shift semantics. For example: int n; ... if( (5 << n) < 0 ) ... would be greeted with the message that the less-than always evaluates to 'False'. It is true that if you shift 5 left by 29 bits (or 31 bits) you will have in many cases (probably most cases) a negative number but this is not guaranteed. According to the C Standard [4], shifting a positive signed integer (5 in this case) left by a number of places (n in this case) is only valid if the type can accomodate 5*(2**n). This is equivalent to not shifting a one into or through the sign bit.
As another example: int n; ... if( (n >> 5) >= 0 ) ... would always be regarded as true. This is because shifting a negative number to the right yields results that are implementation defined.
See also Message 587.</description>
</rule>
<rule>
<key>591</key>
<configkey>591</configkey>
<priority>MAJOR</priority>
<name>Variable 'Symbol' depends on the order of evaluation; it is used/modified through function 'Symbol' via calls: String"</name>
<description>The indicated variable (given by the first Symbol) was involved in an expression that contained a call of a function (given by the second Symbol) that would use or modify the variable. Further, the order of evaluation of the two is not determinable. For example: extern int n; void f() { n++; } int g() { f(); return 1; } int h() { return n + g(); } // Warning 591 The above code, on the second pass, will elicit the following warning: Warning 591: Variable 'n' depends on the order of evaluation; it is modified through function 'g(void)' via calls: g() => f() If the function g() is called and then n is added, you will obtain a different result than if n were first evaluated and then the call made.
The programmer should generally rewrite these expressions so that the compiler is constrained to use the intended order. For example if the programmer wanted to use the n prior to the call on g() it can alter h() to the following: int h() { int k = n; return k + g(); } This analysis requires two passes; the first pass builds the necessary call trees.</description>
</rule>
<rule>
<key>592</key>
<configkey>592</configkey>
<priority>MAJOR</priority>
<name>Non-literal format specifier used without arguments</name>
<description>A printf/scanf style function received a non-literal format specifier without trailing arguments. For example: char msg[100]; ... printf( msg ); This can easily be rewritten to the relatively safe: char msg[100]; ... printf( "%s", msg ); The danger lies in the fact that msg can contain hidden format codes. If msg is read from user input, then in the first example, a naive user could cause a glitch or a crash and a malicious user might exploit this to undermine system security. Since the unsafe form can easily be transformed into the safe form the latter should always be used.</description>
</rule>
<rule>
<key>593</key>
<configkey>593</configkey>
<priority>MAJOR</priority>
<name>Custodial pointer 'Symbol' (Location) possibly not freed or returned</name>
<description>This is the 'possible' version of message 429. A pointer of auto storage class was allocated storage and not all paths leading to a return statement or to the end of the function contained either a free or a return of the pointer. Hence there is a potential memory leak. For example: void f( int n ) { int *p = new int; if( n ) delete p; } // message 593 In this example an allocation is made and, if n is 0, no delete will have been made.
Please see message 429 for an explaination of "custodial" and ways of regulating when pointer variables retain custody of allocations.</description>
</rule>
<rule>
<key>601</key>
<configkey>601</configkey>
<priority>MAJOR</priority>
<name>Expected a type for symbol Symbol, int assumed</name>
<description>A declaration did not have an explicit type. int was assumed. Was this a mistake? This could easily happen if an intended comma was replaced by a semicolon. For example, if instead of typing: double radius, diameter; the programmer had typed: double radius; diameter; this message would be raised.</description>
</rule>
<rule>
<key>602</key>
<configkey>602</configkey>
<priority>MAJOR</priority>
<name>Comment within comment</name>
<description>The sequence /* was found within a comment. Was this deliberate? Or was a comment end inadvertently omitted? If you want PC-lint/FlexeLint to recognize nested comments you should set the Nested Comment flag using the +fnc option. Then this warning will not be issued. If it is your practice to use the sequence: /* /* */
then use -e602.</description>
</rule>
<rule>
<key>603</key>
<configkey>603</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' (Location) not initialized</name>
<description>The address of the named symbol is being passed to a function where the corresponding parameter is declared as pointer to const. This implies that the function will not modify the object. If this is the case then the original object should have been initialized sometime earlier.</description>
</rule>
<rule>
<key>604</key>
<configkey>604</configkey>
<priority>MAJOR</priority>
<name>Returning address of auto variable 'Symbol'</name>
<description>The address of the named symbol is being passed back by a function. Since the object is an auto and since the duration of an auto is not guaranteed past the return, this is most likely an error. You may want to copy the value into a global variable and pass back the address of the global or you might consider having the caller pass an address of one of its own variables to the callee.</description>
</rule>
<rule>
<key>605</key>
<configkey>605</configkey>
<priority>MAJOR</priority>
<name>Increase in pointer capability (Context)</name>
<description>This warning is typically caused by assigning a (pointer to const) to an ordinary pointer. For example: int *p; const int *q; p = q; /* 605 */ The message will be inhibited if a cast is used as in:
p = (int *) q;
An increase in capability is indicated because the const pointed to by q can now be modified through p. This message can be given for the volatile qualifier as well as the const qualifier and may be given for arbitrary pointer depths (pointers to pointers, pointers to arrays, etc.).
If the number of pointer levels exceeds one, things get murky in a hurry. For example: const char ** ppc; char ** pp; pp = ppc; /* 605 - clearly not safe */ ppc = pp; /* 605 - looks safe but it's not */ It was not realized by the C community until very recently that assigning pp to ppc was dangerous. The problem is that after the above assignment, a pointer to a const char can be assigned indirectly through ppc and accessed through pp which can then modify the const char.
The message speaks of an "increase in capability" in assigning to ppc, which seems counter intuitive because the indirect pointer has less capability. However, assigning the pointer does not destroy the old one and the combination of the two pointers represents a net increase in capability.
The message may also be given for function pointer assignments when the prototype of one function contains a pointer of higher capability than a corresponding pointer in another prototype. There is a curious inversion here whereby a prototype of lower capability translates into a function of greater trust and hence greater capability (a Trojan Horse). For example, let
void warrior( char * );
be a function that destroys its argument. Consider the function:
void Troy( void (*horse)(const char *) );
Troy() will call horse() with an argument that it considers precious believing the horse() will do no harm. Before compilers knew better and believing that adding in a const to the destination never hurt anything, earlier compilers allowed the Greeks to pass warrior() to Troy and the rest, as they say, is history.</description>
</rule>
<rule>
<key>606</key>
<configkey>606</configkey>
<priority>MAJOR</priority>
<name>Non-ANSI escape sequence: '\String'</name>
<description>An escape sequence occurred, within a character or string literal, that was not on the approved list which is:
\' \" \? \\ \a \b \f \n \r \t \v
\octal-digits \xhex-digits</description>
</rule>
<rule>
<key>607</key>
<configkey>607</configkey>
<priority>MAJOR</priority>
<name>Parameter 'Symbol' of macro found within string</name>
<description>The indicated name appeared within a string or character literal within a macro and happens to be the same as the name of a formal parameter of the macro as in:
#define mac(n) printf( "n = %d,", n );
Is this a coincidence? The ANSI standard indicates that the name will not be replaced but since many C compilers do replace such names the construction is suspect. Examine the macro definition and if you do not want substitution, change the name of the parameter. If you do want substitution, set the +fps flag (Parameter within String) and suppress the message with -e607.</description>
</rule>
<rule>
<key>608</key>
<configkey>608</configkey>
<priority>MAJOR</priority>
<name>Assigning to an array parameter</name>
<description>An assignment is being made to a parameter that is typed array. For the purpose of the assignment, the parameter is regarded as a pointer. Normally such parameters are typed as pointers rather than arrays. However if this is your coding style you should suppress this message.</description>
</rule>
<rule>
<key>609</key>
<configkey>609</configkey>
<priority>MAJOR</priority>
<name>Suspicious pointer conversion</name>
<description>An assignment is being made between two pointers which differ in size (one is far and the other is near) but which are otherwise compatible.</description>
</rule>
<rule>
<key>610</key>
<configkey>610</configkey>
<priority>MAJOR</priority>
<name>Suspicious pointer combination</name>
<description>Pointers of different size (one is far and the other is near) are being compared, subtracted, or paired (in a conditional expression). This is suspicious because normally pointers entering into such operations are the same size.</description>
</rule>
<rule>
<key>611</key>
<configkey>611</configkey>
<priority>MAJOR</priority>
<name>Suspicious cast</name>
<description>Either a pointer to a function is being cast to a pointer to an object or vice versa. This is regarded as questionable by the ANSI standard. If this is not a user error, suppress this warning.</description>
</rule>
<rule>
<key>612</key>
<configkey>612</configkey>
<priority>MAJOR</priority>
<name>Expected a declarator</name>
<description>A declaration contained just a storage class and a type. This is almost certainly an error since the only time a type without a declarator makes sense is in the case of a struct, union or enum but in that case you wouldn't use a storage class.</description>
</rule>
<rule>
<key>613</key>
<configkey>613</configkey>
<priority>MAJOR</priority>
<name>Possible use of null pointer 'Symbol' in [left/right] argument to operator 'String' Reference</name>
<description>From information gleaned from earlier statements, it is possible that a null pointer (a pointer whose value is 0) can be used in a context where null pointers are inappropriate. Such contexts include: Unary *, pointer increment (++) or decrement(--), addition of pointer to numeric, and subtraction of two pointers. In the case of binary operators, one of the words 'left' or 'right' is used to designate which operand is null. Symbol identifies the pointer variable that may be NULL. See also messages 413 and 794.</description>
</rule>
<rule>
<key>614</key>
<configkey>614</configkey>
<priority>MAJOR</priority>
<name>auto aggregate initializer not constant</name>
<description>An initializer for an auto aggregate normally consists of a collection of constant-valued expressions. Some compilers may, however, allow variables in this context in which case you may suppress this message.</description>
</rule>
<rule>
<key>615</key>
<configkey>615</configkey>
<priority>MAJOR</priority>
<name>auto aggregate initializer has side effects</name>
<description>This warning is similar to 614. Auto aggregates (arrays, structures and union) are normally initialized by a collection of constant-valued expressions without side-effects. A compiler could support side-effects in which case you might want to suppress this message.</description>
</rule>
<rule>
<key>616</key>
<configkey>616</configkey>
<priority>MAJOR</priority>
<name>control flows into case/default</name>
<description>It is possible for flow of control to fall into a case statement or a default statement from above. Was this deliberate or did the programmer forget to insert a break statement? If this was deliberate then place a comment immediately before the statement that was flagged as in:
case 'a': a = 0; /* fall through */ case 'b': a++;
Note that the message will not be given for a case that merely follows another case without an intervening statement. Also, there must actually be a possibility for flow to occur from above.</description>
</rule>
<rule>
<key>617</key>
<configkey>617</configkey>
<priority>MAJOR</priority>
<name>String is both a module and an include file</name>
<description>The named file is being used as both an include file and as a module. Was this a mistake? Unlike Error 306 (repeated module) this is just a warning and processing of the file is attempted.</description>
</rule>
<rule>
<key>618</key>
<configkey>618</configkey>
<priority>MAJOR</priority>
<name>Storage class specified after a type</name>
<description>A storage class specifier (static, extern, typedef, register or auto) was found after a type was specified. This is legal but deprecated. Either place the storage class specifier before the type or suppress this message.</description>
</rule>
<rule>
<key>619</key>
<configkey>619</configkey>
<priority>MAJOR</priority>
<name>Loss of precision (Context) (Pointer to Pointer)</name>
<description>A far pointer is being assigned to a near pointer either in an assignment statement or an implied assignment such as an initializer, a return statement, or passing an argument in the presence of a prototype (Context indicates which). Such assignments are a frequent source of error when the actual segment is not equal to the default data segment. If you are sure that the segment of the far pointer equals the default data segment you should use a cast to suppress this message.</description>
</rule>
<rule>
<key>620</key>
<configkey>620</configkey>
<priority>MAJOR</priority>
<name>Suspicious constant (L or one?)</name>
<description>A constant ended in a lower-case letter 'l'. Was this intended to be a one? The two characters look very similar. To avoid misinterpretations, use the upper-case letter 'L'.</description>
</rule>
<rule>
<key>621</key>
<configkey>621</configkey>
<priority>MAJOR</priority>
<name>Identifier clash (Symbol 'Name' with Symbol 'Name' at String)</name>
<description>The two symbols appeared in the same name space but are identical to within the first count characters set by option -idlen(count,option). See -idlen.</description>
</rule>
<rule>
<key>622</key>
<configkey>622</configkey>
<priority>MAJOR</priority>
<name>Size of argument no. Integer inconsistent with format</name>
<description>The argument to scanf, fscanf or sscanf, where position is given by Integer, was a pointer whose size did not match the format. For example,
int far *p; scanf( "%d", p );
will draw this warning (in the default memory model).</description>
</rule>
<rule>
<key>623</key>
<configkey>623</configkey>
<priority>MAJOR</priority>
<name>redefining the storage class of symbol 'Symbol' (TypeDiff) conflicts with Location</name>
<description>An inter-module symbol was a typedef symbol in one module and an ordinary symbol in another module. This is legal but potentially confusing. Is this what the programmer intended?</description>
</rule>
<rule>
<key>624</key>
<configkey>624</configkey>
<priority>MAJOR</priority>
<name>typedef 'Symbol' redeclared (TypeDiff) (Location)</name>
<description>A symbol was declared in a typedef differently in two different modules. This is technically legal but is not a wise programming practice.</description>
</rule>
<rule>
<key>625</key>
<configkey>625</configkey>
<priority>MAJOR</priority>
<name>auto symbol 'Symbol' has unusual type modifier</name>
<description>Some type modifiers such as far, near, fortran are inappropriate for auto variables.</description>
</rule>
<rule>
<key>626</key>
<configkey>626</configkey>
<priority>MAJOR</priority>
<name>argument no. Integer inconsistent with format</name>
<description>The argument to a printf (or fprintf or sprintf) was inconsistent with the format. Although the size of the quantity was appropriate the type was not. You might consider casting the quantity to the correct type. You could also suppress this message, as more flagrant violations are picked up with warning 559.</description>
</rule>
<rule>
<key>627</key>
<configkey>627</configkey>
<priority>MAJOR</priority>
<name>(arg. no. Integer) indirect object inconsistent with format</name>
<description>The type of an argument to scanf (or fscanf or sscanf) was inappropriate to the format. However, the argument was a pointer and it pointed to a quantity of the expected size.</description>
</rule>
<rule>
<key>628</key>
<configkey>628</configkey>
<priority>MAJOR</priority>
<name>no argument information provided for function 'Symbol' (Location)</name>
<description>The named function was called but there was no argument information supplied. Argument information can come from a prototype or from a function definition. This usually happens when an old-style function declaration indicates that the function is in a library but no prototype is given for the function nor is any argument information provided in a standard library file. This message is suppressed if you are producing a lint object module because presumably the object module will be compared with a library file at some later time.</description>
</rule>
<rule>
<key>629</key>
<configkey>629</configkey>
<priority>MAJOR</priority>
<name>static class for function 'Symbol' is non standard</name>
<description>A static class was found for a function declaration within a function. The static class is only permitted for functions in declarations that have file scope (i.e., outside any function). Either move the declaration outside the function or change static to extern; if the second choice is made, make sure that a static declaration at file scope also exists before the extern declaration. Though technically the construct is not portable, many compilers do tolerate it. If you suppress the message, PC-lint/FlexeLint will treat it as a proper function declaration.</description>
</rule>
<rule>
<key>630</key>
<configkey>630</configkey>
<priority>MAJOR</priority>
<name>ambiguous reference to symbol 'Name'</name>
<description>If the +fab flag is set, then if two structures containing the same member name (not necessarily different kinds of structures) are embedded in the same structure and a reference to this member name omits one of the intervening (disambiguating) names, this warning is emitted.</description>
</rule>
<rule>
<key>631</key>
<configkey>631</configkey>
<priority>MAJOR</priority>
<name>tag 'Symbol' defined differently at Location</name>
<description>The struct, union or enum tag Symbol was defined differently in different scopes. This is not necessarily an error since C permits the redefinition, but it can be a source of subtle error. It is not generally a programming practice to be recommended.</description>
</rule>
<rule>
<key>632</key>
<configkey>632</configkey>
<priority>MAJOR</priority>
<name>Assignment to strong type 'Name' in context: Context</name>
<description>An assignment (or implied assignment, Context indicates which) violates a Strong type check as requested by a -strong(A... option.</description>
</rule>
<rule>
<key>633</key>
<configkey>633</configkey>
<priority>MAJOR</priority>
<name>Assignment from a strong type 'Name' in context: Context</name>
<description>An assignment (or implied assignment, Context indicates which) violates a Strong type check as requested by a -strong(X... option.</description>
</rule>
<rule>
<key>634</key>
<configkey>634</configkey>
<priority>MAJOR</priority>
<name>Strong type mismatch (type 'Symbol') in equality or conditional</name>
<description>An equality operation (== or !=) or a conditional operation (? :) violates a Strong type check as requested by a -strong(J... option. This message would have been suppressed using flags "Je".</description>
</rule>
<rule>
<key>635</key>
<configkey>635</configkey>
<priority>MAJOR</priority>
<name>resetting strong parent of type 'Symbol', old parent == type 'Symbol'</name>
<description>The strong parent of the given Symbol is being reset. This is being done with a -parent option or by a typedef. Note that this may not necessarily be an error; you are being alerted to the fact that the old link is being erased.</description>
</rule>
<rule>
<key>636</key>
<configkey>636</configkey>
<priority>MAJOR</priority>
<name>ptr to strong type 'Name' versus another type</name>
<description>Pointers are being compared and there is a strong type clash below the first level. For example,
/*lint -strong(J,INT) */ typedef int INT; INT *p; int *q;
if( p == q ) /* Warning 636 */
will elicit this warning. This message would have been suppressed using flags "Je" or "Jr" or both.</description>
</rule>
<rule>
<key>637</key>
<configkey>637</configkey>
<priority>MAJOR</priority>
<name>Expected index type 'Symbol' for strong type 'Symbol'</name>
<description>This is the message you receive when an inconsistency with the -index option is recognized. A subscript is not the stipulated type (the first type mentioned in the message) nor equivalent to it within the hierarchy of types.</description>
</rule>
<rule>
<key>638</key>
<configkey>638</configkey>
<priority>MAJOR</priority>
<name>Strong type mismatch for type 'Name' in relational</name>
<description>A relational operation ( >= <= > < ) violates a Strong type check as requested by a -strong(J... option. This message would have been suppressed using flags "Jr".</description>
</rule>
<rule>
<key>639</key>
<configkey>639</configkey>
<priority>MAJOR</priority>
<name>Strong type mismatch for type 'Name' in binary operation</name>
<description>A binary operation other than an equality or a relational operation violates a Strong type check as requested by a -strong(J... option. This message would have been suppressed using flags "Jo".</description>
</rule>
<rule>
<key>640</key>
<configkey>640</configkey>
<priority>MAJOR</priority>
<name>Expected strong type 'Name' in Boolean context</name>
<description>A Boolean context expected a type specified by a -strong(B... option.</description>
</rule>
<rule>
<key>641</key>
<configkey>641</configkey>
<priority>MAJOR</priority>
<name>Converting enum to int</name>
<description>An enumeration type was used in a context that required a computation such as an argument to an arithmetic operator or was compared with an integral argument. This warning will be suppressed if you use the integer model of enumeration (+fie) but you will lose some valuable type-checking in doing so. An intermediate policy is to simply turn off this warning. Assignment of int to enum will still be caught.
This warning is not issued for a tagless enum without variables. For example
enum {false,true};
This cannot be used as a separate type. PC-lint/FlexeLint recognizes this and treats false and true as arithmetic constants.</description>
</rule>
<rule>
<key>642</key>
<configkey>642</configkey>
<priority>MAJOR</priority>
<name>Format char 'Char' not supported by wsprintf</name>
<description>This means that you are using an option of the form: -printf(w... and you are using a format character not supported by the Microsoft Windows function wsprintf. If you are not really using wsprintf but are using the w flag to get far pointers you should turn this message off.</description>
</rule>
<rule>
<key>643</key>
<configkey>643</configkey>
<priority>MAJOR</priority>
<name>Loss of precision in pointer cast</name>
<description>A far pointer was cast to a near pointer. Such casts have had disastrous consequences for Windows programmers. If you really need to make such a cast, you can do it in stages. If you cast to a long first (i.e., some integral type that can hold the pointer) and then into a shorter value, we don't complain.</description>
</rule>
<rule>
<key>644</key>
<configkey>644</configkey>
<priority>MAJOR</priority>
<name>Variable 'Symbol' (Location) may not have been initialized</name>
<description>An auto variable was not necessarily assigned a value before use.</description>
</rule>
<rule>
<key>645</key>
<configkey>645</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' (Location) may not have been initialized</name>
<description>An auto variable was conditionally assigned a value before being passed to a function expecting a pointer to a const object. See Warning 603 for an explanation of the dangers of such a construct.</description>
</rule>
<rule>
<key>646</key>
<configkey>646</configkey>
<priority>MAJOR</priority>
<name>case/default within Kind loop; may have been misplaced</name>
<description>A case or default statement was found within a for, do, or while loop. Was this intentional? At the very least, this reflects poor programming style.</description>
</rule>
<rule>
<key>647</key>
<configkey>647</configkey>
<priority>MAJOR</priority>
<name>Suspicious truncation</name>
<description>This message is issued when it appears that there may have been an unintended loss of information during an operation involving int or unsigned int the result of which is later converted to long. It is issued only for systems in which int is smaller than long. For example:
(long) (n << 8)
might elicit this message if n is unsigned int, whereas
(long) n << 8
would not. In the first case, the shift is done at int precision and the high order 8 bits are lost even though there is a subsequent conversion to a type that might hold all the bits. In the second case, the shifted bits are retained.
The operations that are scrutinized and reported upon by this message are: shift left, multiplication, and bit-wise complementation. Addition and subtraction are covered by Informational message 776.</description></rule>
The conversion to long may be done explicitly with a cast as shown or implicitly via assignment, return, argument passing or initialization.
The message can be suppressed by casting. You may cast one of the operands so that the operation is done in full precision as is given by the second example above. Alternatively, if you decide there is really no problem here (for now or in the future), you may cast the result of the operation to some form of int. For example, you might write:
(long) (unsigned) (n << 8)
In this way PC-lint/FlexeLint will know you are aware of and approve of the truncation.</description>
</rule>
<rule>
<key>648</key>
<configkey>648</configkey>
<priority>MAJOR</priority>
<name>Overflow in computing constant for operation: String</name>
<description>Arithmetic overflow was detected while computing a constant expression. For example, if int is 16 bits then 200 * 200 will result in an overflow. String gives the operation that caused the overflow and may be one of: addition, unsigned addition, multiplication, unsigned multiplication, negation, shift left, unsigned shift left, subtraction, or unsigned sub.
To suppress this message for particular constant operations you may have to supply explicit truncation. For example, if you want to obtain the low order 8 bits of the integer 20000 into the high byte of a 16-bit int, shifting left would cause this warning. However, truncating first and then shifting would be OK. The following code illustrates this where int is 16 bits. 20000u << 8; /* 648 */ (0xFF & 20000u) << 8; /* OK */ If you truncate with a cast you may make a signed expression out of an unsigned. For example, the following receives a warning (for 16 bit int).
(unsigned char) OxFFFu << 8 /* 648 */
because the unsigned char is promoted to int before shifting. The resulting quantity is actually negative. You would need to revive the unsigned nature of the expression with
(unsigned) (unsigned char) OxFFF << 8 /* OK */</description>
</rule>
<rule>
<key>649</key>
<configkey>649</configkey>
<priority>MAJOR</priority>
<name>Sign fill during constant shift</name>
<description>During the evaluation of a constant expression a negative integer was shifted right causing sign fill of vacated positions. If this is what is intended, suppress this error, but be aware that sign fill is implementation-dependent.</description>
</rule>
<rule>
<key>650</key>
<configkey>650</configkey>
<priority>MAJOR</priority>
<name>Constant out of range for operator String</name>
<description>In a comparison operator or equality test (or implied equality test as for a case statement), a constant operand is not in the range specified by the other operand. For example, if 300 is compared against a char variable, this warning will be issued. Moreover, if char is signed (and 8 bits) you will get this message if you compare against an integer greater than 127. The problem can be fixed with a cast. For example:
if( ch == 0xFF ) ... if( (unsigned char) ch == 0xFF ) ...
If char is signed (+fcu has not been set) the first receives a warning and can never succeed. The second suppresses the warning and corrects the bug.
PC-lint/FlexeLint will take into account the limited precision of some operands such as bit-fields and enumerated types. Also, PC-lint/FlexeLint will take advantage of some computations that limit the precision of an operand. For example,
if( (n & 0xFF) >> 4 == 16 ) ...
will receive this warning because the left-hand side is limited to 4 bits of precision.</description>
</rule>
<rule>
<key>651</key>
<configkey>651</configkey>
<priority>MAJOR</priority>
<name>Potentially confusing initializer</name>
<description>An initializer for a complex aggregate is being processed that contains some subaggregates that are bracketed and some that are not. ANSI recommends either "minimally bracketed" initializers in which there are no interior braces or "fully bracketed" initializers in which all interior aggregates are bracketed.</description>
</rule>
<rule>
<key>652</key>
<configkey>652</configkey>
<priority>MAJOR</priority>
<name>#define of symbol 'Symbol' declared previously at Location</name>
<description>A macro is being defined for a symbol that had previously been declared. For example:
int n; #define n N
will draw this complaint. Prior symbols checked are local and global variables, functions and typedef symbols, and struct, union and enum tags. Not checked are struct and union member.</description>
</rule>
<rule>
<key>653</key>
<configkey>653</configkey>
<priority>MAJOR</priority>
<name>Possible loss of fraction</name>
<description>When two integers are divided and assigned to a floating point variable the fraction portion is lost. For example, although
double x = 5 / 2;
appears to assign 2.5 to x it actually assigns 2.0. To make sure you don't lose the fraction, cast at least one of the operands to a floating point type. If you really wish to do the truncation, cast the resulting divide to an integral (int or long) before assigning to the floating point variable.</description>
</rule>
<rule>
<key>654</key>
<configkey>654</configkey>
<priority>MAJOR</priority>
<name>Option String obsolete; use -width(W,I)</name>
<description>The option -w is now used to set the warning level and should no longer be used to specify the width of error messages. Instead use -width with the same arguments as before to set the width. To set the warning level to 3, for example, use the option -w3, not -w(3).</description>
</rule>
<rule>
<key>655</key>
<configkey>655</configkey>
<priority>MAJOR</priority>
<name>bit-wise operation uses (compatible) enum's</name>
<description>A bit-wise operator (one of '|', '&' or '^') is used to combine two compatible enumerations. The type of the result is considered to be the enumeration. This is considered a very minor deviation from the strict model and you may elect to suppress this warning.</description>
</rule>
<rule>
<key>656</key>
<configkey>656</configkey>
<priority>MAJOR</priority>
<name>Arithmetic operation uses (compatible) enum's</name>
<description>An arithmetic operator (one of '+', or '-') is used to combine two compatible enumerations. The type of the result is considered to be the enumeration. This is considered a very minor deviation from the strict model and you may elect to suppress this warning.</description>
</rule>
<rule>
<key>657</key>
<configkey>657</configkey>
<priority>MAJOR</priority>
<name>Unusual (nonportable) anonymous struct or union</name>
<description>A struct or union declaration without a declarator was taken to be anonymous. However, the anonymous union supported by C++ and other dialects of C require untagged union's. Tagged unions and tagged or untagged structs are rarely supported, as anonymous.</description>
</rule>
<rule>
<key>658</key>
<configkey>658</configkey>
<priority>MAJOR</priority>
<name>Anonymous union assumed (use flag +fan)</name>
<description>A union without a declarator was found. Was this an attempt to define an anonymous union? If so, anonymous unions should be activated with the +fan flag. This flag is activated automatically for C++.</description>
</rule>
<rule>
<key>659</key>
<configkey>659</configkey>
<priority>MAJOR</priority>
<name>Nothing follows '}' on line within struct/union/enum declaration</name>
<description>A struct/union/class/enum definition occurred and the closing '}' was not followed on the same line by another token. It looks suspicious. Missing semi-colons after such definitions can be a source of strange and mysterious messages. If you intentionally omitted the semi-colon then simply place the token which follows on the same line as the '}'. At the very least follow the '}' with a comment.</description>
</rule>
<rule>
<key>660</key>
<configkey>660</configkey>
<priority>MAJOR</priority>
<name>Option 'String' requests removing an extent that is not on the list</name>
<description>A number of options use the '-' prefix to remove and '+' to add elements to a list. For example to add (the most unusual) extension .C++ to designate C++ processing of files bearing that extension, a programmer should employ the option: +cpp(.C++) However, if a leading '-' is employed (a natural mistake) this warning will be emitted.</description>
</rule>
<rule>
<key>661</key>
<configkey>661</configkey>
<priority>MAJOR</priority>
<name>possible access of out-of-bounds pointer ('Integer' beyond end of data) by operator 'String'</name>
<description>An out-of-bounds pointer may have been accessed. See message 415 for a description of the parameters Integer and String. For example: int a[10]; if( n <= 10 ) a[n] = 0;
Here the programmer presumably should have written n<10. This message is similar to messages 415 and 796 but differs from them by the degree of probability.</description>
</rule>
<rule>
<key>662</key>
<configkey>662</configkey>
<priority>MAJOR</priority>
<name>possible creation of out-of-bounds pointer ('Integer' beyond end of data) by operator 'String'</name>
<description>An out-of-bounds pointer may have been created. See message 415 for a description of the parameters Integer and String. For example: int a[10]; if( n <= 20 ) f( a + n );
Here, it appears as though an illicit pointer is being created, but PC-lint/FlexeLint cannot be certain. See also messages 416 and 797.</description>
</rule>
<rule>
<key>663</key>
<configkey>663</configkey>
<priority>MAJOR</priority>
<name>Suspicious array to pointer conversion</name>
<description>This warning occurs in the following kind of situation: struct x { int a; } y[2]; ... y->a ...
Here, the programmer forgot to index the array but the error normally goes undetected because the array reference is automatically and implicitly converted to a pointer to the first element of the array. If you really mean to access the first element use y[0].a.</description>
</rule>
<rule>
<key>664</key>
<configkey>664</configkey>
<priority>MAJOR</priority>
<name>Left side of logical OR (||) or logical AND (&&) does not return</name>
<description>An exiting function was found on the left hand side of an operator implying that the right hand side would never be executed. For example: if( (exit(0),n == 0) || n > 2 ) ...
Since the exit function does not return, control can never flow to the right hand operator.</description>
</rule>
<rule>
<key>665</key>
<configkey>665</configkey>
<priority>MAJOR</priority>
<name>Unparenthesized parameter Integer in macro 'Symbol' is passed an expression</name>
<description>An expression was passed to a macro parameter that was not parenthesized. For example: #define mult(a,b) (a*b) ... mult( 100, 4 + 10 )
Here the programmer is beguiled into thinking that the 4+10 is taken as a quantity to be multiplied by 100 but instead results in: 100*4+10 which is quite different. The recommended remedy ([22, ?20.4]) is to parenthesize such parameters as in:
#define mult(a,b) ((a)*(b))
The message is not arbitrarily given for any unparenthesized parameter but only when the actual macro argument sufficiently resembles an expression and the expression involves binary operators. The priority of the operator is not considered except that it must have lower priority than the unary operators. The message is not issued at the point of macro definition because it may not be appropriate to parenthesize the parameter. For example, the following macro expects that an operator will be passed as argument. It would be an error to enclose op in parentheses.
#define check(x,op,y) if( ((x) op (y)) == 0 ) print( ... )</description>
</rule>
<rule>
<key>666</key>
<configkey>666</configkey>
<priority>MAJOR</priority>
<name>Expression with side effects passed to repeated parameter Integer of macro 'Symbol'</name>
<description>A repeated parameter within a macro was passed an argument with side-effects. For example: #define ABS(x) ((x) < 0 ? -(x) : (x))
... ABS( n++ )
Although the ABS macro is correctly defined to specify the absolute value of its argument, the repeated use of the parameter x implies a repeated evaluation of the actual argument n++. This results in two increments to the variable n. [22, ?20.6] Any expression containing a function call is also considered to have side-effects.</description>
</rule>
<rule>
<key>667</key>
<configkey>667</configkey>
<priority>MAJOR</priority>
<name>Inconsistent use of qualifiers for symbol 'Symbol' (type 'Type' vs. 'Type') conflicts with Location</name>
<description>A declaration for the identified Symbol is inconsistent with a prior declaration for the same symbol. There was a nominal difference in the declaration but owing to the memory model chosen there was no real difference. For example, in large model, one declaration declares external symbol alpha to be a far pointer and another declaration omits the memory model specification.</description>
</rule>
<rule>
<key>668</key>
<configkey>668</configkey>
<priority>MAJOR</priority>
<name>Possibly passing a null pointer to function 'Symbol', Context Reference</name>
<description>A NULL pointer is possibly being passed to a function identified by Symbol. The argument in question is given by Context. The function is either a library function designed not to receive a NULL pointer or a user function dubbed so via the option -function.</description>
</rule>
<rule>
<key>669</key>
<configkey>669</configkey>
<priority>MAJOR</priority>
<name>Possible data overrun for function 'Symbol', argument Integer exceeds argument Integer Reference</name>
<description>This message is for data transfer functions such as memcpy, strcpy, fgets, etc. when the size indicated by the first cited argument (or arguments) can possibly exceed the size of the buffer area cited by the second. The message may also be issued for user functions via the -function option.</description>
</rule>
<rule>
<key>670</key>
<configkey>670</configkey>
<priority>MAJOR</priority>
<name>Possible access beyond array for function 'Symbol', argument Integer exceeds Integer Reference</name>
<description>This message is issued for several library functions (such as fwrite, memcmp, etc) wherein there is a possible attempt to access more data than exist. For example, if the length of data specified in the fwrite call exceeds the size of the data specified. The function is specified by Symbol and the arguments are identified by argument number.</description>
</rule>
<rule>
<key>671</key>
<configkey>671</configkey>
<priority>MAJOR</priority>
<name>Possibly passing to function 'Symbol' a negative value (Integer), Context Reference</name>
<description>An integral value that may possibly be negative is being passed to a function that is expecting only positive values for a particular argument. The message contains the name of the function (Symbol), the questionable value (Integer) and the argument number (Context). The function may be a standard library function designed to accept only positive values such as malloc or memcpy (third argument), or may have been identified by the user as such through the -function or -sem options. See message 422 for an example and further explanation.</description>
</rule>
<rule>
<key>672</key>
<configkey>672</configkey>
<priority>MAJOR</priority>
<name>Possible memory leak in assignment to pointer 'Symbol'</name>
<description>An assignment was made to a pointer variable (designated by Symbol) which may already be holding the address of an allocated object which had not been freed. The allocation of memory which is not freed is considered a 'memory leak'. The memory leak is considered 'possible' because only some lines of flow will result in a leak.</description>
</rule>
<rule>
<key>673</key>
<configkey>673</configkey>
<priority>MAJOR</priority>
<name>Possibly inappropriate deallocation (Name1) for 'Name2' data.</name>
<description>This message indicates that a deallocation (free(), delete, or delete[]) as specified by String1 may be inappropriate for the data being freed. The kind of data is one or more of: malloc, new, new[], static, auto, member, modified or constant. The word 'Possibly' is used in the message to indicate that only some of the lines of flow to the deallocation show data inconsistent with the allocation.</description>
</rule>
<rule>
<key>674</key>
<configkey>674</configkey>
<priority>MAJOR</priority>
<name>Returning address of auto through variable 'Symbol'.</name>
<description>The value held by a pointer variable contains the address of an auto variable. It is normally incorrect to return the address of an item on the stack because the portion of the stack allocated to the returning function is subject to being obliterated after return.</description>
</rule>
<rule>
<key>675</key>
<configkey>675</configkey>
<priority>MAJOR</priority>
<name>No prior semantics associated with 'Name' in option 'String'</name>
<description>The -function option is used to transfer semantics from its first argument to subsequent arguments. However it was found that the first argument Name did not have semantics.</description>
</rule>
<rule>
<key>676</key>
<configkey>676</configkey>
<priority>MAJOR</priority>
<name>Possibly negative subscript (Integer) in operator 'String'</name>
<description>An integer whose value was possibly negative was added to an array or to a pointer to an allocated area (allocated by malloc, operator new, etc.) This message is not given for pointers whose origin is unknown since a negative subscript is in general legal.</description>
</rule>
<rule>
<key>677</key>
<configkey>677</configkey>
<priority>MAJOR</priority>
<name>sizeof used within preprocessor statement.</name>
<description>Whereas the use of sizeof during preprocessing is supported by a number of compilers it is not a part of the ANSI C or C++ standard.</description>
</rule>
<rule>
<key>678</key>
<configkey>678</configkey>
<priority>MAJOR</priority>
<name>Member 'Symbol' field length (Integer) too small for enum precision (Integer)</name>
<description>A bit field was found to be too small to support all the values of an enumeration (that was used as the base of the bit field). For example: enum color { red, green, yellow, blue }; struct abc { enum color c:2; };
Here, the message is not given because the four enumeration values of color will just fit within 2 bits. However, if one additional color is inserted, Warning 678 will be issued informing the programmer of the undesirable and dangerous condition.</description>
</rule>
<rule>
<key>679</key>
<configkey>679</configkey>
<priority>MAJOR</priority>
<name>Suspicious Truncation in arithmetic expression combining with pointer</name>
<description>This message is issued when it appears that there may have been an unintended loss of information during an operation involving integrals prior to combining with a pointer whose precision is greater than the integral expression. For example: //lint -sp8 pointers are 8 bytes //lint -si4 integers are 4 bytes char *f( char *p, int n, int m ) { return p + (n + m); // warning 679 }
By the rules of C/C++, the addition n+m is performed independently of its context and is done at integer precision. Any overflow is ignored even though the larger precision of the pointer could easily accommodate the overflow. If, on the other hand the expression were: p+n+m, which parses as (p+n)+m, no warning would be issued.
If the expression were p + n * m then, to suppress the warning, a cast is needed. If long were the same size as pointers you could use the expression:
return p + ((long) n * m);</description>
</rule>
<rule>
<key>680</key>
<configkey>680</configkey>
<priority>MAJOR</priority>
<name>Suspicious Truncation in arithmetic expression converted to pointer</name>
<description>An arithmetic expression was cast to pointer. Moreover, the size of the pointer is greater than the size of the expression. In computing the expression, any overflow would be lost even though the pointer type would be able to accommodate the lost information. To suppress the message, cast one of the operands to an integral type large enough to hold the pointer. Alternatively, if you are sure there is no problem you may cast the expression to an integral type before casting to pointer. See messages 647, 776, 790 and 679.</description>
</rule>
<rule>
<key>681</key>
<configkey>681</configkey>
<priority>MAJOR</priority>
<name>Loop is not entered</name>
<description>The controlling expression for a loop (either the expression within a while clause or the second expression within a for clause) evaluates initially to 0 and so it appears as though the loop is never entered.</description>
</rule>
<rule>
<key>682</key>
<configkey>682</configkey>
<priority>MAJOR</priority>
<name>sizeof applied to a parameter 'Symbol' whose type is a sized array</name>
<description>If a parameter is typed as an array it is silently promoted to pointer. Taking the size of such an array will actually yield the size of a pointer. Consider, for example:
unsigned f( char a[100] ) { return sizeof(a); }
Here it looks as though function f() will return the value 100 but it will actually return the size of a pointer which is usually 4.</description>
</rule>
<rule>
<key>683</key>
<configkey>683</configkey>
<priority>MAJOR</priority>
<name>function 'Symbol' #define'd</name>
<description>This message is issued whenever the name of a function with some semantic association is defined as a macro. For example:
#define strlen mystrlen
will raise this message. The problem is that the semantics defined for strlen will then be lost. Consider this message an alert to transfer semantics from strlen to mystrlen, using -function(strlen, mystrlen) The message will be issued for built-in functions (with built-in semantics) or for user-defined semantics. The message will not be issued if the function is defined to be a function with a similar name but with underscores either appended or prepended or both. For example:
#define strlen __strlen
will not produce this message. It will produce Info 828 instead.</description>
</rule>
<rule>
<key>684</key>
<configkey>684</configkey>
<priority>MAJOR</priority>
<name>Passing address of auto variable 'Symbol' into caller space</name>
<description>The address of an auto variable was passed via assignment into a location specified by the caller to the function. For example: void f( int *a[] ) { int n; a[1] = &n; }
Here the address of an auto variable (n) is being passed into the second element of the array passed to the function f. This looks suspicious because upon return the array will contain a pointer to a variable whose lifetime is over. It is possible that this is benign since it could be that the caller to f() is merely passing in a working space to be discarded upon return. If this is the case, you can suppress the message for function f() using the option
-efunc(684,f).
See also Warning 604.</description>
</rule>
<rule>
<key>685</key>
<configkey>685</configkey>
<priority>MAJOR</priority>
<name>Relational operator 'String,' always evaluates to 'String'</name>
<description>The first String is one of '>', '>=', '<' or '<=' and identifies the relational operator. The second string is one of 'True' or 'False,0>'. The message is given when an expression is compared to a constant and the precision of the expression indicates that the test will always succeed or always fail. For example, char ch; ... if( ch >= -128 ) ...
In this example, the precision of char ch is 8 bits signed (assuming the fcu flag has been left in the OFF state) and hence it has a range of values from -128 to 127 inclusive. Hence the trest is always True.
Note that, technically, ch is promoted to int before comparing with the constant. For the purpose of this comparison we consider only the underlying precision. As another example, if u is an unsigned int then
if( (u & 0xFF) > 0xFF ) ...
will also raise a 685 because the expression on the left hand side has an effective precision of 16 bits.</description>
</rule>
<rule>
<key>686</key>
<configkey>686</configkey>
<priority>MAJOR</priority>
<name>Option 'String' is suspicious because of 'Name'</name>
<description>An option is considered suspicious for one of a variety of reasons. The reason is designated by a reason code that is specified by Name. At this writing, the only reason code is 'unbalanced quotes'.</description>
</rule>
<rule>
<key>687</key>
<configkey>687</configkey>
<priority>MAJOR</priority>
<name>Suspicious use of comma operator</name>
<description>A comma operator appeared unbraced and unparenthesized in a statement following an if, else, while or for clause. For example: if( n > 0 ) n = 1, n = 2; Thus the comma could be mistaken for a semi-colon and hence be the source of subtle bugs.
If the statement is enclosed in curly braces or if the expression is enclosed in parentheses, the message is not issued.</description>
</rule>
<rule>
<key>688</key>
<configkey>688</configkey>
<priority>MAJOR</priority>
<name>Cast used within a preprocessor conditional statement</name>
<description>A cast was used within a preprocessor conditional statement such as #if or #elif. As an example you may have written: #define VERSION 11.3 ... #if (int) VERSION == 11 ... #endif Such casts are not allowed by the various C and C++ standards.</description>
</rule>
<rule>
<key>689</key>
<configkey>689</configkey>
<priority>MAJOR</priority>
<name>Apparent end of comment ignored</name>
<description>The pair of characters '*/' was found not within a comment. As an example: void f( void*/*comment*/ ); This is taken to be the equivalent of: void f( void* ); That is, an implied blank is inserted between the '*' and the '/'. To avoid this message simply place an explicit blank between the two characters.</description>
</rule>
<rule>
<key>690</key>
<configkey>690</configkey>
<priority>MAJOR</priority>
<name>Possible access of pointer pointing Integer bytes past nul character by operator 'String'</name>
<description>Accessing past the terminating nul character is often an indication of a programmer error. For example: char buf[20]; char c; strcpy( buf, "a" ); if( i < 20 ) c = buf[i]; // legal but suspect. See also Warning 448 in Section 13.3 and Info 836 in Section 13.4</description>
</rule>
<rule>
<key>691</key>
<configkey>691</configkey>
<priority>MAJOR</priority>
<name>Suspicious use of backslash</name>
<description>The backslash character has been used in a way that may produce unexpected results. Typically this would occur within a macro such as: #define A b \ // comment The coder might be thinking that the macro definition will be continued on to the next line. The standard indicates, however, that the newline will not be dropped in the event of an intervening comment. This should probably be recoded as: #define A b /* comment */ \</description>
</rule>
<rule>
<key>692</key>
<configkey>692</configkey>
<priority>MAJOR</priority>
<name>Decimal character 'Char' follows octal escape sequence 'String'</name>
<description>A String was found that contains an '8' or '9' after an octal escape sequence with no more than two octal digits, e.g. "\079" contains two characters: Octal seven (ASCII BEL) followed by '9'. The casual reader of the code (and perhaps even the programmer) could be fooled into thinking this is a single character. If this is what the programmer intended he can also render this as "\07" "9" so that there can be no misunderstanding.
On the other hand, "\1238" will not raise a message because it is assumed that the programmer knows that octal escape sequences cannot exceed four characters (including the initial backslash).</description>
</rule>
<rule>
<key>693</key>
<configkey>693</configkey>
<priority>MAJOR</priority>
<name>Hexadecimal digit 'Char' immediately after 'String' is suspicious in string literal.</name>
<description>A String was found that looks suspiciously like (but is not) a hexadecimal escape sequence; rather, it is a null character followed by letter "x" followed by some hexadecimal digit, e.g.: "\0x62" was found where the programmer probably meant to type "\x62". If you need precisely this sequence you can use: "\0" "x62" and this warning will not be issued.</description>
</rule>
<rule>
<key>694</key>
<configkey>694</configkey>
<priority>MAJOR</priority>
<name>The type of constant 'String' (precision Integer) is dialect dependent</name>
<description>A decimal integer constant that requires all the bits of an unsigned long for its representation has a type that depends on the dialect of C or C++ implemented by the compiler you are using. For example, the constant 3000000000 requires 32 bits for its representation. If longs are 32 bits, then the constant is judged to be unsigned long in C90, long long in C99 and undefined in C++.
You can remove the ambiguity by applying a clarifying suffix. If you intend this to be unsigned use the 'U' suffix. If you intend this to be a long long use the 'LL' suffix. If the latter and you are using C++ then turn on the +fll flag.</description>
</rule>
<rule>
<key>695</key>
<configkey>695</configkey>
<priority>MAJOR</priority>
<name>Inline function 'Symbol' defined without a storage-class specifier ('static' recommended)</name>
<description>In C99, the result of a call to a function declared with 'inline' but not 'static' or 'extern' is unspecified.
Example: Let the following text represent two translation units: /* In module_1.c */ void f() {}
/* In module_2.c */ inline void f() {} void g() { f(); } /* which f() is called? */ The C99 Standard dictates that the above call to f() from g() in module_2.c may result in the execution of either f().
The programmer may avoid confusion and improve portability by using the keyword 'static' in addition to 'inline'. The keyword 'extern' can also be used along with the 'inline' to resolve this ambiguity; however, we recommend using 'static' because, as of this writing, more compilers correctly interpret 'static inline'.</description>
</rule>
<rule>
<key>696</key>
<configkey>696</configkey>
<priority>MAJOR</priority>
<name>Variable 'Symbol' has value 'String' that is out of range for operator 'String'</name>
<description>The variable cited in the message is being compared (using one of the 6 comparison operations) with some other expression called the comperand. The variable has a value that is out of the range of values of this comperand. For example consider: void f( unsigned char ch ) { int n = 1000; if( ch < n ) // Message 696 ... Here a message 696 will be issued stating that n has a value of 1000 that is out of range because 1000 is not in the set of values that ch can hold (assuming default sizes of scalars).</description>
</rule>
<rule>
<key>697</key>
<configkey>697</configkey>
<priority>MAJOR</priority>
<name>Quasi-boolean values should be equality-compared only with 0</name>
<description>A quasi-boolean value is being compared (using either != or ==) with a value that is not the literal zero. A quasi-boolean value is any value whose type is a strong boolean type and that could conceivably be something other than zero or one. This is significant because in C, all non-zero values are equally true. Example: /*lint -strong(AJXb, B) */ typedef int B; #define YES ((B)1) #define NO ((B)0)
B f( B a, B b ) { B c = ( a == NO ); /* OK, no Warning here */ B d = ( a == (b != NO) ); /* Warning 697 for == but not for != */ B e = ( a == YES ); /* Warning 697 here */ return d == c; /* Warning 697 here */ } Note that if a and b had instead been declared with true boolean types, such as 'bool' in C++ or '_Bool' in C99, this diagnostic would not have been issued.</description>
</rule>
<rule>
<key>698</key>
<configkey>698</configkey>
<priority>MAJOR</priority>
<name>Casual use of realloc can create a memory leak</name>
<description>A statement of the form: v = realloc( v, ... ); has been detected. Note the repeated use of the same variable. The problem is that realloc can fail to allocate the necessary storage. In so doing it will return NULL. But then the original value of v is overwritten resulting in a memory leak.</description>
</rule>
<rule>
<key>701</key>
<configkey>701</configkey>
<priority>MINOR</priority>
<name>Shift left of signed quantity (int)</name>
<description>Shifts are normally accomplished on unsigned operands.</description>
</rule>
<rule>
<key>702</key>
<configkey>702</configkey>
<priority>MINOR</priority>
<name>Shift right of signed quantity (int)</name>
<description>Shifts are normally accomplished on unsigned operands. Shifting an int right is machine dependent (sign fill vs. zero fill).</description>
</rule>
<rule>
<key>703</key>
<configkey>703</configkey>
<priority>MINOR</priority>
<name>Shift left of signed quantity (long)</name>
<description>Shifts are normally accomplished on unsigned operands.</description>
</rule>
<rule>
<key>704</key>
<configkey>704</configkey>
<priority>MINOR</priority>
<name>Shift right of signed quantity (long)</name>
<description>Shifts are normally accomplished on unsigned operands. Shifting a long right is machine dependent (sign fill vs. zero fill).</description>
</rule>
<rule>
<key>705</key>
<configkey>705</configkey>
<priority>MINOR</priority>
<name>Argument no. Integer nominally inconsistent with format</name>
<description>The argument to a printf (or fprintf or sprintf) was nominally inconsistent with the format. Although the size of the quantity was appropriate the type was similar, but not exact. (E.g., passing a long to a %d or an int to a %x) You might consider casting the quantity to the correct type. You could also suppress this message, as more flagrant violations are picked up with warnings 559 and 626.</description>
</rule>
<rule>
<key>706</key>
<configkey>706</configkey>
<priority>MINOR</priority>
<name>(arg. no. Integer) indirect object inconsistent with format</name>
<description>The type of an argument to scanf (or fscanf or sscanf) was inappropriate to the format. However, the argument was a pointer and it pointed to a quantity of the expected size and similar, but not expected type.</description>
</rule>
<rule>
<key>707</key>
<configkey>707</configkey>
<priority>MINOR</priority>
<name>Mixing narrow and wide string literals in concatenation.</name>
<description>The following is an example of a mixing of narrow and wide string literals. const wchar_t *s = "abc" L"def"; The concatenation of narrow and wide string literals results in undefined behavior for C90 and C++2003. If your compiler supports such combinations or you use a C/C++ dialect that supports such, you may either suppress this message or consider making the concatenands match.</description>
</rule>
<rule>
<key>708</key>
<configkey>708</configkey>
<priority>MINOR</priority>
<name>union initialization</name>
<description>There was an attempt to initialize the value of a union. This may not be permitted in some older C compilers. This is because of the apparent ambiguity: which member should be initialized. The standard interpretation is to apply the initialization to the first subtype of the union.</description>
</rule>
<rule>
<key>712</key>
<configkey>712</configkey>
<priority>MINOR</priority>
<name>Loss of precision (Context) (Type to Type)</name>
<description>An assignment (or implied assignment, see Context) is being made between two integral quantities in which the first Type is larger than the second Type. A cast will suppress this message.</description>
</rule>
<rule>
<key>713</key>
<configkey>713</configkey>
<priority>MINOR</priority>
<name>Loss of precision (Context) (Type to Type)</name>
<description>An assignment (or implied assignment, see Context) is being made from an unsigned quantity to a signed quantity, that will result in the possible loss of one bit of integral precision such as converting from unsigned int to int. A cast will suppress the message.</description>
</rule>
<rule>
<key>714</key>
<configkey>714</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' (Location) not referenced</name>
<description>The named external variable or external function was defined but not referenced. This message is suppressed for unit checkout (-u option).</description>
</rule>
<rule>
<key>715</key>
<configkey>715</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' (Location) not referenced</name>
<description>The named formal parameter was not referenced.</description>
</rule>
<rule>
<key>716</key>
<configkey>716</configkey>
<priority>MINOR</priority>
<name>while(1) ...</name>
<description>A construct of the form while(1) ... was found. Whereas this represents a constant in a context expecting a Boolean, it may reflect a programming policy whereby infinite loops are prefixed with this construct. Hence it is given a separate number and has been placed in the informational category. The more conventional form of infinite loop prefix is for(;;).</description>
</rule>
<rule>
<key>717</key>
<configkey>717</configkey>
<priority>MINOR</priority>
<name>do ... while(0)</name>
<description>Whereas this represents a constant in a context expecting a Boolean, this construct is probably a deliberate attempt on the part of the programmer to encapsulate a sequence of statements into a single statement, and so it is given a separate error message. [22, ?20.7] For example:
#define f(k) do {n=k; m=n+1;} while(0)
allows f(k) to be used in conditional statements as in
if(n>0) f(3); else f(2);
Thus, if you are doing this deliberately use -e717</description>
</rule>
<rule>
<key>718</key>
<configkey>718</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' undeclared, assumed to return int</name>
<description>A function was referenced without (or before) it had been declared or defined within the current module. This is not necessarily an error and you may want to suppress such messages. Note that by adding a declaration to another module, you will not suppress this message. It can only be suppressed by placing a declaration within the module being processed.</description>
</rule>
<rule>
<key>719</key>
<configkey>719</configkey>
<priority>MINOR</priority>
<name>Too many arguments for format (Integer too many)</name>
<description>The number of arguments to a function in the printf/scanf family was more than what is specified in the format. This message is similar to Warning 558 which alerts users to situations in which there were too few arguments for the format. It receives a lighter Informational classification because the additional arguments are simply ignored.</description>
</rule>
<rule>
<key>720</key>
<configkey>720</configkey>
<priority>MINOR</priority>
<name>Boolean test of assignment</name>
<description>An assignment was found in a context that requires a Boolean (such as in an if() or while() clause or as an operand to && or ||). This may be legitimate or it could have resulted from a mistaken use of = for ==.</description>
</rule>
<rule>
<key>721</key>
<configkey>721</configkey>
<priority>MINOR</priority>
<name>Suspicious use of ;</name>
<description>A semi-colon was found immediately to the right of a right parenthesis in a construct of the form if(e);. As such it may be overlooked or confused with the use of semi-colons to terminate statements. The message will be inhibited if the ';' is separated by at least one blank from the ')'. Better, place it on a separate line. See also message 548.</description>
</rule>
<rule>
<key>722</key>
<configkey>722</configkey>
<priority>MINOR</priority>
<name>Suspicious use of ;</name>
<description>A semi-colon was found immediately to the right of a right parenthesis in a construct of the form while(e); or for(e;e;e);. As such it may be overlooked or confused with the use of semi-colons to terminate statements. The message will be inhibited if the ';' is separated by at least one blank from the ')'. Better, place it on a separate line.</description>
</rule>
<rule>
<key>723</key>
<configkey>723</configkey>
<priority>MINOR</priority>
<name>Suspicious use of =</name>
<description>A preprocessor definition began with an = sign. For example:
#define LIMIT = 50
Was this intentional? Or was the programmer thinking of assignment when he wrote this?</description>
</rule>
<rule>
<key>725</key>
<configkey>725</configkey>
<priority>MINOR</priority>
<name>Expected positive indentation from Location</name>
<description>The current line was found to be aligned with, rather than indented with respect to, the indicated line. The indicated line corresponds to a clause introducing a control structure and statements within its scope are expected to be indented with respect to it. If tabs within your program are other than 8 blanks you should use the -t option.</description>
</rule>
<rule>
<key>726</key>
<configkey>726</configkey>
<priority>MINOR</priority>
<name>Extraneous comma ignored</name>
<description>A comma followed by a right-brace within an enumeration is not a valid ANSI construct. The comma is ignored.</description>
</rule>
<rule>
<key>727</key>
<configkey>727</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' (Location) not explicitly initialized</name>
<description>The named static variable (local to a function) was not explicitly initialized prior to use. The following remarks apply to messages 728 and 729 as well as 727. By no explicit initialization we mean that there was no initializer present in the definition of the object, no direct assignment to the object, and no address operator applied to the object or, if the address of the object was taken, it was assigned to a pointer to const. These messages do not necessarily signal errors since the implicit initialization for static variables is 0. However, the messages are helpful in indicating those variables that you had forgotten to initialize to a value. To extract the maximum benefit from the messages we suggest that you employ an explicit initializer for those variables that you want to initialize to 0. For example:
static int n = 0;
For variables that will be initialized dynamically, do not use an explicit initializer as in:
static int m;
This message will be given for any array, struct or union if no member or element has been assigned a value.</description>
</rule>
<rule>
<key>728</key>
<configkey>728</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' (Location) not explicitly initialized</name>
<description>The named intra-module variable (static variable with file scope) was not explicitly initialized. See the comments on message 727 for more details.</description>
</rule>
<rule>
<key>729</key>
<configkey>729</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' (Location) not explicitly initialized</name>
<description>The named inter-module variable (external variable) was not explicitly initialized. See the comments on message 727 for more details. This message is suppressed for unit checkout (-u).</description>
</rule>
<rule>
<key>730</key>
<configkey>730</configkey>
<priority>MINOR</priority>
<name>Boolean argument to function</name>
<description>A Boolean was used as an argument to a function. Was this intended? Or was the programmer confused by a particularly complex conditional statement. Experienced C programmers often suppress this message. This message is given only if the associated parameter is not declared bool.</description>
</rule>
<rule>
<key>731</key>
<configkey>731</configkey>
<priority>MINOR</priority>
<name>Boolean argument to equal/not equal</name>
<description>A Boolean was used as an argument to == or !=. For example:
if( (a > b) == (c > d) ) ...
tests to see if the inequalities are of the same value. This could be an error as it is an unusual use of a Boolean (see Warnings 503 and 514) but it may also be deliberate since this is the only way to efficiently achieve equivalence or exclusive or. Because of this possible use, the construct is given a relatively mild 'informational' classification. If the Boolean argument is cast to some type, this message is not given.</description>
</rule>
<rule>
<key>732</key>
<configkey>732</configkey>
<priority>MINOR</priority>
<name>Loss of sign (Context) (Type to Type)</name>
<description>An assignment (or implied assignment, see Context) is made from a signed quantity to an unsigned quantity. Also, it could not be determined that the signed quantity had no sign. For example:
u = n; /* Info 732 */ u = 4; /* OK */
where u is unsigned and n is not, warrants a message only for the first assignment, even though the constant 4 is nominally a signed int.
Make sure that this is not an error (that the assigned value is never negative) and then use a cast (to unsigned) to remove the message.</description>
</rule>
<rule>
<key>733</key>
<configkey>733</configkey>
<priority>MINOR</priority>
<name>Assigning address of auto variable 'Symbol' to outer scope symbol 'Symbol'</name>
<description>The address of an auto variable is only valid within the block in which the variable is declared. An address to such a variable has been assigned to a variable that has a longer life expectancy. There is an inherent danger in doing this.</description>
</rule>
<rule>
<key>734</key>
<configkey>734</configkey>
<priority>MINOR</priority>
<name>Loss of precision (Context) (Integer bits to Integer bits)</name>
<description>An assignment is being made into an object smaller than an int. The information being assigned is derived from another object or combination of objects in such a way that information could potentially be lost. The number of bits given does not count the sign bit. For example if ch is a char and n is an int then:
ch = n;
will trigger this message whereas:
ch = n & 1;
will not. To suppress the message a cast can be made as in:
ch = (char) n;
You may receive notices involving multiplication and shift operators with subinteger variables. For example:
ch = ch << 2 ch = ch * ch
where, for example, ch is an unsigned char. These can be suppressed by using the flag +fpm (precision of an operator is bound by the maximum of its operands).</description>
</rule>
<rule>
<key>735</key>
<configkey>735</configkey>
<priority>MINOR</priority>
<name>Loss of precision (Context) (Integer bits to Integer bits)</name>
<description>An assignment (or implied assignment, see Context) is made from a long double to a double. Using a cast will suppress the message. The number of bits includes the sign bit.</description>
</rule>
<rule>
<key>736</key>
<configkey>736</configkey>
<priority>MINOR</priority>
<name>Loss of precision (Context) (Integer bits to Integer bits)</name>
<description>An assignment (or implied assignment, see Context) is being made to a float from a value or combination of values that appear to have higher precision than a float. You may suppress this message by using a cast. The number of bits includes the sign bit.</description>
</rule>
<rule>
<key>737</key>
<configkey>737</configkey>
<priority>MINOR</priority>
<name>Loss of sign in promotion from Type to Type</name>
<description>An unsigned quantity was joined with a signed quantity in a binary operator (or 2nd and 3rd arguments to the conditional operator ? :) and the signed quantity is implicitly converted to unsigned. The message will not be given if the signed quantity is an unsigned constant, a Boolean, or an expression involving bit manipulation. For example,
u & ~0xFF
where u is unsigned does not draw the message even though the operand on the right is technically a signed integer constant. It looks enough like an unsigned to warrant not giving the message.
This mixed mode operation could also draw Warnings 573 or 574 depending upon which operator is involved.
You may suppress the message with a cast but you should first determine whether the signed value could ever be negative or whether the unsigned value can fit within the constraints of a signed quantity.</description>
</rule>
<rule>
<key>738</key>
<configkey>738</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' (Location) not explicitly initialized</name>
<description>The named static local variable was not initialized before being passed to a function whose corresponding parameter is declared as pointer to const. Is this an error or is the programmer relying on the default initialization of 0 for all static items. By employing an explicit initializer you will suppress this message. See also message numbers 727 and 603.</description>
</rule>
<rule>
<key>739</key>
<configkey>739</configkey>
<priority>MINOR</priority>
<name>Trigraph Sequence 'String' in literal (Quiet Change)</name>
<description>The indicated Trigraph (three-character) sequence was found within a string. This trigraph reduces to a single character according to the ANSI standard. This represents a "Quiet Change" from the past where the sequence was not treated as exceptional. If you had no intention of mapping these characters into a single character you may precede the initial '?' with a backslash. If you are aware of the convention and you intend that the Trigraph be converted you should suppress this informational message.</description>
</rule>
<rule>
<key>740</key>
<configkey>740</configkey>
<priority>MINOR</priority>
<name>Unusual pointer cast (incompatible indirect types)</name>
<description>A cast is being made to convert one pointer to another such that neither of the pointers is a generic pointer (neither is pointer to char, unsigned char, or void) and the indirect types are truly different. The message will not be given if the indirect types differ merely in signedness (e.g., pointer to unsigned versus pointer to int) or in qualification (e.g., pointer to const int versus pointer to int). The message will also not be given if one of the indirect types is a union.
The main purpose of this message is to report possible problems for machines in which pointer to char is rendered differently from pointer to word. Consider casting a pointer to pointer to char to a pointer to pointer to word. The indirect bit pattern remains unchanged.
A second reason is to identify those pointer casts in which the indirect type doesn't seem to have the proper bit pattern such as casting from a pointer to int to a pointer to double.
If you are not interested in running on machines in which char pointers are fundamentally different from other pointers then you may want to suppress this message. You can also suppress this message by first casting to char pointer or to void pointer but this is only recommended if the underlying semantics are right.</description>
</rule>
<rule>
<key>741</key>
<configkey>741</configkey>
<priority>MINOR</priority>
<name>Unusual pointer cast (function qualification)</name>
<description>A cast is being made between two pointers such that their indirect types differ in one of the Microsoft qualifiers: pascal, fortran, cdecl and interrupt. If this is not an error you may cast to a more neutral pointer first such as a void *.</description>
</rule>
<rule>
<key>742</key>
<configkey>742</configkey>
<priority>MINOR</priority>
<name>Multiple character constant</name>
<description>A character constant was found that contained multiple characters, e.g., 'ab'. This is legal C but the numeric value of the constant is implementation defined. It may be safe to suppress this message because, if more characters are provided than what can fit in an int, message number 25 is given.</description>
</rule>
<rule>
<key>743</key>
<configkey>743</configkey>
<priority>MINOR</priority>
<name>Negative character constant</name>
<description>A character constant was specified whose value is some negative integer. For example, on machines where a byte is 8 bits, the character constant '\xFF' is flagged because its value (according to the ANSI standard) is -1 (its type is int). Note that its value is not 0xFF.</description>
</rule>
<rule>
<key>744</key>
<configkey>744</configkey>
<priority>MINOR</priority>
<name>switch statement has no default</name>
<description>A switch statement has no section labeled default:. Was this an oversight? It is standard practice in many programming groups to always have a default: case. This can lead to better (and earlier) error detection. One way to suppress this message is by introducing a vacuous default: break; statement. If you think this adds too much overhead to your program, think again. In all cases tested so far, the introduction of this statement added absolutely nothing to the overall length of code. If you accompany the vacuous statement with a suitable comment, your code will at least be more readable.
This message is not given if the control expression is an enumerated type. In this case, all enumerated constants are expected to be represented by case statements, else 787 will be issued.</description>
</rule>
<rule>
<key>745</key>
<configkey>745</configkey>
<priority>MINOR</priority>
<name>function 'Name' has no explicit type or class, int assumed</name>
<description>A function declaration or definition contained no explicit type. Was this deliberate?</description>
</rule>
<rule>
<key>746</key>
<configkey>746</configkey>
<priority>MINOR</priority>
<name>call to function 'Name' not made in the presence of a prototype</name>
<description>A call to a function is not made in the presence of a prototype. This does not mean that PC-lint/FlexeLint is unaware of any prototype; it means that a prototype is not in a position for a compiler to see it. If you have not adopted a strict prototyping convention you will want to suppress this message with -e746.</description>
</rule>
<rule>
<key>747</key>
<configkey>747</configkey>
<priority>MINOR</priority>
<name>Significant prototype coercion (Context) Type to Type</name>
<description>The type specified in the prototype differed from the type provided as an argument in some significant way. Usually the two types are arithmetic of differing sizes or one is float and the other integral. This is flagged because if the program were to be translated by a compiler that does not support prototype conversion, the conversion would not be performed.</description>
</rule>
<rule>
<key>748</key>
<configkey>748</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' (Location) is a register variable used with setjmp</name>
<description>The named variable is a register variable and is used within a function that calls upon setjmp. When a subsequent longjmp is issued the values of register variables may be unpredictable. If this error is not suppressed for this variable, the variable is marked as uninitialized at this point in the program.</description>
</rule>
<rule>
<key>749</key>
<configkey>749</configkey>
<priority>MINOR</priority>
<name>local enumeration constant 'Symbol' (Location) not referenced</name>
<description>A member (name provided as Symbol) of an enum was defined in a module but was not otherwise used within that module. A 'local' member is one that is not defined in a header file. Compare with messages 754 and 769.</description>
</rule>
<rule>
<key>750</key>
<configkey>750</configkey>
<priority>MINOR</priority>
<name>local macro 'Symbol' (Location) not referenced</name>
<description>A 'local' macro is one that is not defined in a header file. The macro was not referenced throughout the module in which it is defined.</description>
</rule>
<rule>
<key>751</key>
<configkey>751</configkey>
<priority>MINOR</priority>
<name>local typedef 'Symbol' (Location) not referenced</name>
<description>A 'local' typedef symbol is one that is not defined in any header file. It may have file scope or block scope but it was not used through its scope.</description>
</rule>
<rule>
<key>752</key>
<configkey>752</configkey>
<priority>MINOR</priority>
<name>local declarator 'Symbol' (Location) not referenced</name>
<description>A 'local' declarator symbol is one declared in a declaration which appeared in the module file itself as opposed to a header file. The symbol may have file scope or may have block scope. But it wasn't referenced.</description>
</rule>
<rule>
<key>753</key>
<configkey>753</configkey>
<priority>MINOR</priority>
<name>local struct, union or enum tag 'Symbol' (Location) not referenced</name>
<description>A 'local' tag is one not defined in a header file. Since its definition appeared, why was it not used? Use of a tag is implied by the use of any of its members.</description>
</rule>
<rule>
<key>754</key>
<configkey>754</configkey>
<priority>MINOR</priority>
<name>local structure member 'Symbol' (Location) not referenced</name>
<description>A member (name provided as Symbol) of a struct or union was defined in a module but was not otherwise used within that module. A 'local' member is one that is not defined in a header file. See message 768.</description>
</rule>
<rule>
<key>755</key>
<configkey>755</configkey>
<priority>MINOR</priority>
<name>global macro 'Symbol' (Location) not referenced</name>
<description>A 'global' macro is one defined in a header file. This message is given for macros defined in non-library headers. The macro is not used in any of the modules comprising the program. This message is suppressed for unit checkout (-u option).</description>
</rule>
<rule>
<key>756</key>
<configkey>756</configkey>
<priority>MINOR</priority>
<name>global typedef 'Symbol' (Location) not referenced</name>
<description>This message is given for a typedef symbol declared in a non-library header file. The symbol is not used in any of the modules comprising a program. This message is suppressed for unit checkout (-u option).</description>
</rule>
<rule>
<key>757</key>
<configkey>757</configkey>
<priority>MINOR</priority>
<name>global declarator 'Symbol' (Location) not referenced</name>
<description>This message is given for objects that have been declared in non-library header files and that have not been used in any module comprising the program being checked. The message is suppressed for unit checkout (-u).</description>
</rule>
<rule>
<key>758</key>
<configkey>758</configkey>
<priority>MINOR</priority>
<name>global struct, union or enum tag 'Symbol' (Location) not referenced</name>
<description>This message is given for struct, union and enum tags that have been defined in non-library header files and that have not been used in any module comprising the program. The message is suppressed for unit checkout (-u).</description>
</rule>
<rule>
<key>759</key>
<configkey>759</configkey>
<priority>MINOR</priority>
<name>header declaration for symbol 'Symbol' (Location) could be moved from header to module</name>
<description>This message is given for declarations, within non-library header files, that are not referenced outside the defining module. Hence, it can be moved inside the module and thereby 'lighten the load' on all modules using the header. This message is only given when more than one module is being linted.</description>
</rule>
<rule>
<key>760</key>
<configkey>760</configkey>
<priority>MINOR</priority>
<name>Redundant macro 'Symbol' defined identically at Location</name>
<description>The given macro was defined earlier (location given) in the same way and is hence redundant.</description>
</rule>
<rule>
<key>761</key>
<configkey>761</configkey>
<priority>MINOR</priority>
<name>Redundant typedef 'Symbol' previously declared at Location</name>
<description>A typedef symbol has been typedefed earlier at the given location. Although the declarations are consistent you should probably remove the second.</description>
</rule>
<rule>
<key>762</key>
<configkey>762</configkey>
<priority>MINOR</priority>
<name>Redundantly declared symbol 'Symbol' previously declared at Location</name>
<description>A declaration for the given symbol was found to be consistent with an earlier declaration in the same scope. This declaration adds nothing new and it can be removed.</description>
</rule>
<rule>
<key>763</key>
<configkey>763</configkey>
<priority>MINOR</priority>
<name>Redundant declaration for symbol 'Symbol' previously declared at Location</name>
<description>A tag for a struct, union or enum was defined twice in the same module (consistently). The second one can be removed.</description>
</rule>
<rule>
<key>764</key>
<configkey>764</configkey>
<priority>MINOR</priority>
<name>switch statement does not have a case</name>
<description>A switch statement has been found that does not have a case statement associated with it (it may or may not have a default statement). This is normally a useless construct.</description>
</rule>
<rule>
<key>765</key>
<configkey>765</configkey>
<priority>MINOR</priority>
<name>external 'Symbol' (Location) could be made static</name>
<description>An external symbol was referenced in only one module. It was not declared static (and its type is not qualified with the Microsoft keyword __export). Some programmers like to make static every symbol they can, because this lightens the load on the linker. It also represents good documentation. On the other hand, you may want the symbol to remain external because debuggers often work only on external names. It's possible, using macros, to have the best of both worlds.</description>
</rule>
<rule>
<key>766</key>
<configkey>766</configkey>
<priority>MINOR</priority>
<name>Header file FileName not used in module String</name>
<description>The named header file was directly #include'd in the named module but the #include can be removed because it was not used in processing the named module or in any header included by the module. It contained no macro, typedef, struct, union or enum tag or component, or declaration referenced by the module. One of the reasons a particular #include can be removed is because it had been included by an earlier header file. Warning 537 can be used to detect such cases.</description>
</rule>
<rule>
<key>767</key>
<configkey>767</configkey>
<priority>MINOR</priority>
<name>macro 'Symbol' was defined differently in another module (Location)</name>
<description>Two macros processed in two different modules had inconsistent definitions.</description>
</rule>
<rule>
<key>768</key>
<configkey>768</configkey>
<priority>MINOR</priority>
<name>global struct member 'Symbol' (Location) not referenced</name>
<description>A member (name provided as Symbol) of a struct or union appeared in a non-library header file but was not used in any module comprising the program. This message is suppressed for unit checkout. Since struct's may be replicated in storage, finding an unused member can pay handsome storage dividends. However, many structures merely reflect an agreed upon convention for accessing storage and for any one program many members are unused. In this case, receiving this message can be a nuisance. One convenient way to avoid unwanted messages (other than the usual -e and -esym) is to always place such structures in library header files. Alternatively, you can place the struct within a ++flb ... --flb sandwich to force it to be considered library.</description>
</rule>
<rule>
<key>769</key>
<configkey>769</configkey>
<priority>MINOR</priority>
<name>global enumeration constant 'Symbol' (Location) not referenced</name>
<description>A member (name provided as Symbol) of an enum appeared in a non-library header file but was not used in any module comprising the program. This message is suppressed for unit checkout. There are reasons why a programmer may occasionally want to retain an unused enum and for this reason this message is distinguished from 768 (unused member). See message 768 for ways of selectively suppressing this message.</description>
</rule>
<rule>
<key>770</key>
<configkey>770</configkey>
<priority>MINOR</priority>
<name>tag 'Symbol' defined identically at Location</name>
<description>The struct, union, or enum tag Symbol was defined identically in different locations (usually two different files). This is not an error but it is not necessarily good programming practice either. It is better to place common definitions of this kind in a header file where they can be shared among several modules. If you do this, you will not get this message. Note that if the tag is defined differently in different scopes, you will receive warning 631 rather than this message.</description>
</rule>
<rule>
<key>771</key>
<configkey>771</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' (Location) conceivably not initialized</name>
<description>The named symbol, declared at Location, was initialized in the main portion of a control loop (while, for, or do) and subsequently used outside the loop. If it is possible for the main body of the loop to not be fully executed, then the given symbol would remain uninitialized resulting in an error.
PC-lint/FlexeLint does not do a great job of evaluating expressions and hence may not recognize that a loop is executed at least once. This is particularly true after initializing an array. Satisfy yourself that the loop is executed and then suppress the message. You may wish to suppress the message globally with -e771 or just for specific symbols using -esym. Don't forget that a simple assignment statement may be all that's needed to suppress the message.</description>
</rule>
<rule>
<key>772</key>
<configkey>772</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' (Location) conceivably not initialized</name>
<description>The address of the named Symbol was passed to a function expecting to receive a pointer to a const item. This requires the Symbol to have been initialized. See Warning 603 for an explanation of the dangers of such a construct. See Informational message 771 for an explanation of "conceivably not initialized."</description>
</rule>
<rule>
<key>773</key>
<configkey>773</configkey>
<priority>MINOR</priority>
<name>Expression-like macro 'Symbol' not parenthesized</name>
<description>A macro that appeared to be an expression contained unparenthesized binary operators and therefore may result in unexpected associations when used with other operators. For example,
#define A B + 1
may be used later in the context:
f( A * 2 );
with the surprising result that B+2 gets passed to f and not the (B+1)*2 corrective action is to define A as:
#define A (B + 1)
Lowest precedence binary operators are not reported upon. Thus:
#define A s.x
does not elicit this message because this case does not seem to represent a problem. Also, unparenthesized unary operators (including casts) do not generate this message. Information about such unparenthesized parameters can be found by enabling Elective Note 973. [22, ?20.5]</description>
</rule>
<rule>
<key>774</key>
<configkey>774</configkey>
<priority>MINOR</priority>
<name>Boolean within 'String' always evaluates to [True/False]</name>
<description>The indicated clause (String is one of if, while or for (2nd expression)) has an argument that appears to always evaluate to either 'True' or 'False' (as indicated in the message). Information is gleaned from a variety of sources including prior assignment statements and initializers. Compare this with message 506 which is based on testing constants or combinations of constants. Also compare with the Elective Note 944 which can sometimes provide more detailed information.</description>
</rule>
<rule>
<key>775</key>
<configkey>775</configkey>
<priority>MINOR</priority>
<name>non-negative quantity cannot be less than zero</name>
<description>A non-negative quantity is being compared for being <=0. This is a little suspicious since a non-negative quantity can be equal to 0 but never less than 0. The non-negative quantity may be of type unsigned or may have been promoted from an unsigned type or may have been judged not to have a sign by virtue of it having been AND'ed with a quantity known not to have a sign bit an enum that may not be negative, etc. See also Warning 568.</description>
</rule>
<rule>
<key>776</key>
<configkey>776</configkey>
<priority>MINOR</priority>
<name>Possible truncation of addition</name>
<description>An int expression (signed or unsigned) involving addition or subtraction is converted to long implicitly or explicitly. Moreover, the precision of a long is greater than that of int. If an overflow occurred, information would be lost. Either cast one of the operands to some form of long or cast the result to some form of int.
See Warning 647 for a further description and an example of this kind of error. See also 790 and 942.</description>
</rule>
<rule>
<key>777</key>
<configkey>777</configkey>
<priority>MINOR</priority>
<name>Testing float's for equality</name>
<description>This message is issued when the operands of operators == and != are some form of floating type (float, double, or long double). Testing for equality between two floating point quantities is suspect because of round-off error and the lack of perfect representation of fractions. If your numerical algorithm calls for such testing turn the message off. The message is suppressed when one of the operands can be represented exactly, such as 0 or 13.5.</description>
</rule>
<rule>
<key>778</key>
<configkey>778</configkey>
<priority>MINOR</priority>
<name>Constant expression evaluates to 0 in operation: String</name>
<description>A constant expression involving addition, subtraction, multiplication, shifting, or negation resulted in a 0. This could be a purposeful computation but could also have been unintended. If this is intentional, suppress the message. If one of the operands is 0 Elective Note 941 may be issued rather than a 778.</description>
</rule>
<rule>
<key>779</key>
<configkey>779</configkey>
<priority>MINOR</priority>
<name>String constant in comparison operator: Operator</name>
<description>A string constant appeared as an argument to a comparison operator. For example:
if( s == "abc" ) ...
This is usually an error. Did the programmer intend to use strcmp? It certainly looks suspicious. At the very least, any such comparison is bound to be machine-dependent. If you cast the string constant, the message is suppressed.</description>
</rule>
<rule>
<key>780</key>
<configkey>780</configkey>
<priority>MINOR</priority>
<name>Vacuous array element</name>
<description>A declaration of an array looks suspicious because the array element is an array of 0 dimension. For example:
extern int a[][]; extern int a[10][];
will both emit this message but
extern int a[][10];
will not. In the latter case, proper array accessing will take place even though the outermost dimension is missing.
If extern were omitted, the construct would be given a more serious error message.</description>
</rule>
<rule>
<key>782</key>
<configkey>782</configkey>
<priority>MINOR</priority>
<name>Line exceeds Integer characters</name>
<description>An internal limit on the size of the input buffer has been reached. The message contains the maximum permissible size. This does not necessarily mean that the input will be processed erroneously. Additional characters will be read on a subsequent read. However the line sequence numbers reported on messages will be incorrect.</description>
</rule>
<rule>
<key>783</key>
<configkey>783</configkey>
<priority>MINOR</priority>
<name>Line does not end with new-line</name>
<description>This message is issued when an input line is not terminated by a new-line or when a NUL character appears within an input line. When input lines are read, an fgets is used. A strlen call is made to determine the number of characters read. If the new-line character is not seen at the presumed end, this message is issued. If your editor is in the habit of not appending new-lines onto the end of the last line of the file then suppress this message. Otherwise, examine the file for NUL characters and eliminate them.</description>
</rule>
<rule>
<key>784</key>
<configkey>784</configkey>
<priority>MINOR</priority>
<name>Nul character truncated from string</name>
<description>During initialization of an array with a string constant there was not enough room to hold the trailing NUL character. For example:
char a[3] = "abc";
would evoke such a message. This may not be an error since the easiest way to do this initialization is in the manner indicated. It is more convenient than: char a[3] = { 'a', 'b', 'c' };
On the other hand, if it really is an error it may be especially difficult to find.</description>
</rule>
<rule>
<key>785</key>
<configkey>785</configkey>
<priority>MINOR</priority>
<name>Too few initializers for aggregate 'Symbol'</name>
<description>The number of initializers in a brace-enclosed initializer was less than the number of items in the aggregate. Default initialization is taken. An exception is made with the initializer {0}. This is given a separate message number in the Elective Note category (943). It is normally considered to be simply a stylized way of initializing all members to 0.</description>
</rule>
<rule>
<key>786</key>
<configkey>786</configkey>
<priority>MINOR</priority>
<name>String concatenation within initializer</name>
<description>Although it is perfectly 'legal' to concatenate string constants within an initializer, this is a frequent source of error. Consider:
char *s[] = { "abc" "def" };
Did the programmer intend to have an array of two strings but forget the comma separator? Or was a single string intended?</description>
</rule>
<rule>
<key>787</key>
<configkey>787</configkey>
<priority>MINOR</priority>
<name>enum constant 'Symbol' not used within switch</name>
<description>A switch expression is an enumerated type and at least one of the enumerated constants was not present as a case label. Moreover, no default case was provided.</description>
</rule>
<rule>
<key>788</key>
<configkey>788</configkey>
<priority>MINOR</priority>
<name>enum constant 'Symbol' not used within defaulted switch</name>
<description>A switch expression is an enumerated type and at least one of the enumerated constants was not present as a case label. However, unlike Info 787, a default case was provided. This is a mild form of the case reported by Info 787. The user may thus elect to inhibit this mild form while retaining Info 787.</description>
</rule>
<rule>
<key>789</key>
<configkey>789</configkey>
<priority>MINOR</priority>
<name>Assigning address of auto variable 'Symbol' to static</name>
<description>The address of an auto variable (Symbol) is being assigned to a static variable. This is dangerous because the static variable will persist after return from the function in which the auto is declared but the auto will be, in theory, gone. This can prove to be among the hardest bugs to find. If you have one of these, make certain there is no error and use -esym to suppress the message for a particular variable.</description>
</rule>
<rule>
<key>790</key>
<configkey>790</configkey>
<priority>MINOR</priority>
<name>Suspicious truncation, integral to float.</name>
<description>This message is issued when it appears that there may have been an unintended loss of information during an operation involving integrals the result of which is later converted to a floating point quantity. The operations that are scrutinized and reported upon by this message are: shift left and multiplication. Addition and subtraction are covered by Elective Note 942. See also 647 and 776.</description>
</rule>
<rule>
<key>791</key>
<configkey>791</configkey>
<priority>MINOR</priority>
<name>unusual option sequence</name>
<description>A temporary message suppression option (one having the form: !e...) followed a regular option. Was this intended?</description>
</rule>
<rule>
<key>792</key>
<configkey>792</configkey>
<priority>MINOR</priority>
<name>void cast of void expression</name>
<description>A void expression has been cast to void. Was this intended?</description>
</rule>
<rule>
<key>793</key>
<configkey>793</configkey>
<priority>MINOR</priority>
<name>ANSI limit of String 'String' 'Name' exceeded -- processing is unaffected</name>
<description>Some ANSI limit has been exceeded. These limits are described in Section 2.2.4.1 of the ANSI C Standard. Programs exceeding these limits are not considered maximally portable. However, they may work for individual compilers.
Many large programs exceed the ANSI limit of 511 external identifiers. This will result in message 793 "ANSI limit of 511 'external identifiers' exceeded". It may not be obvious how to inhibit this message for identifiers while leaving other limits in a reportable state. The second parameter of the message is designated Name and so the -esym may be used. Because the symbol contains a blank, quotes must be used. The option becomes:
-"esym(793,external identifiers)"</description>
</rule>
<rule>
<key>794</key>
<configkey>794</configkey>
<priority>MINOR</priority>
<name>Conceivable use of null pointer 'Symbol' in [left/right] argument to operator 'String' Reference</name>
<description>From information gleaned from earlier statements it is conceivable that a null pointer (a pointer whose value is 0) can be used in a context where null pointers are inappropriate. In the case of binary operators one of the words 'left' or 'right' is used to designate which operand is null. Symbol identifies the pointer variable that may be NULL. This is similar to messages 413 and 613 and differs from them in that the likelihood is not as great. For example: int *p = 0; int i; for( i = 0; i < n; i++ ) p = &a[i]; *p = 0;
If the body of the for loop is never taken then p remains null.</description>
</rule>
<rule>
<key>795</key>
<configkey>795</configkey>
<priority>MINOR</priority>
<name>Conceivable division by 0</name>
<description>In a division or modulus operation the division is deduced to be conceivably 0.</description>
</rule>
<rule>
<key>796</key>
<configkey>796</configkey>
<priority>MINOR</priority>
<name>Conceivable access of out-of-bounds pointer ('Integer' beyond end of data) by operator 'String'</name>
<description>An out-of-bounds pointer may conceivably have been accessed. See message 415 for a description of the parameters Integer and String. For example: int a[10]; int j = 100; for( i = 0; i < n; i++ ) j = n; a[j] = 0;
Here, the access to a[j] is flagged because it is conceivable that the for loop is not executed leaving the unacceptable index of 100 in variable j. This message is similar to messages 415 and 661 but differing from them by the degree of probability.</description>
</rule>
<rule>
<key>797</key>
<configkey>797</configkey>
<priority>MINOR</priority>
<name>Conceivable creation of out-of-bounds pointer ('Integer' beyond end of data) by operator 'String'</name>
<description>An out-of-bounds pointer is potentially being created. See message 415 for a description of the parameters Integer and String. See message 796 for an example of how a probability can be considered 'conceivable'.</description>
</rule>
<rule>
<key>798</key>
<configkey>798</configkey>
<priority>MINOR</priority>
<name>Redundant character 'Char'</name>
<description>The indicated character char is redundant and can be eliminated from the input source. A typical example is a backslash on a line by itself.</description>
</rule>
<rule>
<key>799</key>
<configkey>799</configkey>
<priority>MINOR</priority>
<name>numerical constant 'Integer' larger than unsigned long</name>
<description>An integral constant was found to be larger than the largest value allowed for unsigned long quantities. By default, an unsigned long is 4 bytes but can be respecified via the option -sl#. If the long long type is permitted (see option +fll) this message is automatically suppressed. See also message 417.</description>
</rule>
<rule>
<key>801</key>
<configkey>801</configkey>
<priority>MINOR</priority>
<name>Use of goto is deprecated</name>
<description>A goto was detected. Use of the goto is not considered good programming practice by most authors and its use is normally discouraged. There are a few cases where the goto can be effectively employed but often these can be rewritten just as effectively without the goto. The use of goto's can have a devastating effect on the structure of large functions creating a mass of spaghetti-like confusion. For this reason its use has been banned in many venues.</description>
</rule>
<rule>
<key>802</key>
<configkey>802</configkey>
<priority>MINOR</priority>
<name>Conceivably passing a null pointer to function 'Symbol', Context Reference</name>
<description>A NULL pointer is conceivably being passed to a function identified by Symbol. The argument in question is given by Context. The function is either a library function designed not to receive a NULL pointer or a user function dubbed so via the option -function.</description>
</rule>
<rule>
<key>803</key>
<configkey>803</configkey>
<priority>MINOR</priority>
<name>Conceivable data overrun for function 'Symbol', argument Integer exceeds argument Integer Reference</name>
<description>This message is for data transfer functions such as memcpy, strcpy, fgets, etc. when the size indicated by the first cited argument (or arguments) can conceivably exceed the size of the buffer area cited by the second. The message may also be issued for user functions via the -function option.</description>
</rule>
<rule>
<key>804</key>
<configkey>804</configkey>
<priority>MINOR</priority>
<name>Conceivable access beyond array for function 'Symbol', argument Integer exceeds Integer Reference</name>
<description>This message is issued for several library functions (such as fwrite, memcmp, etc) wherein there is conceivably an attempt to access more data than exist. For example, if the length of data specified in the fwrite call can exceed the size of the data specified. The function is specified by Symbol and the arguments are identified by argument number.</description>
</rule>
<rule>
<key>805</key>
<configkey>805</configkey>
<priority>MINOR</priority>
<name>Expected L"..." to initialize wide char string</name>
<description>An initializer for a wide character array or pointer did not use a preceding 'L'. For example:
wchar_t a[] = "abc";
was found whereas
wchar_t a[] = L"abc":
was expected.</description>
</rule>
<rule>
<key>806</key>
<configkey>806</configkey>
<priority>MINOR</priority>
<name>Small bit field is signed rather than unsigned</name>
<description>A small bit field (less than an int wide) was found and the base type is signed rather than unsigned. Since the most significant bit is a sign bit this practice can produce surprising results. For example, struct { int b:1; } s; s.b = 1; if( s.b > 0 ) /* should succeed but actually fails */ ...</description>
</rule>
<rule>
<key>807</key>
<configkey>807</configkey>
<priority>MINOR</priority>
<name>Conceivably passing to function 'Symbol' a negative value (Integer), Context Reference</name>
<description>An integral value that may conceivably be negative is being passed to a function that is expecting only positive values for a particular argument. The message contains the name of the function (Symbol), the questionable value (Integer) and the argument number (Context). The function may be a standard library function designed to accept only positive values such as malloc or memcpy (third argument), or may have been identified by the user as such through the -function or -sem options. See message 422 for an example and further explanation.</description>
</rule>
<rule>
<key>808</key>
<configkey>808</configkey>
<priority>MINOR</priority>
<name>No explicit type given symbol 'Sybmol', assumed int</name>
<description>An explicit type was missing in a declaration. Unlike Warning 601, the declaration may have been accompanied by a storage class or modifier (qualifier) or both. For example: extern f(void);
will draw message 808. Had the extern not been present, a 601 would have been raised.
The keywords unsigned, signed, short and long are taken to be explicit type specifiers even though int is implicitly assumed as a base.</description>
</rule>
<rule>
<key>809</key>
<configkey>809</configkey>
<priority>MINOR</priority>
<name>Possible return of address of auto through variable 'Symbol'</name>
<description>The value held by a pointer variable may have been the address of an auto variable. It is normally incorrect to return the address of an item on the stack because the portion of the stack allocated to the returning function is subject to being obliterated after return.</description>
</rule>
<rule>
<key>810</key>
<configkey>810</configkey>
<priority>MINOR</priority>
<name>Arithmetic modification of custodial pointer 'Symbol'</name>
<description>810,Arithmetic modification of custodial pointer 'Symbol' We define the custodial variable as that variable directly receiving the result of a malloc or new or equivalent call. It is inappropriate to modify such a variable because it must ultimately be free'ed or delete'ed. You should first make a copy of the custodial pointer and then modify the copy. The copy is known as an alias.</description>
</rule>
<rule>
<key>811</key>
<configkey>811</configkey>
<priority>MINOR</priority>
<name>Possible deallocation of pointer alias</name>
<description>A free or a delete was applied to a pointer that did not appear to be the custodial variable of the storage that had been allocated. Please refer to message 810 for the definition of 'custodial variable'. Deleting an alias pointer is bad because it can result in deleting the same area twice. This can cause strange behavior at unpredictable times. Always try to identify the custodial pointer as opposed to copies (or aliases) of it. Then deallocate storage through the custodial pointer. Modify only the alias pointers.</description>
</rule>
<rule>
<key>812</key>
<configkey>812</configkey>
<priority>MINOR</priority>
<name>static variable 'Symbol' has size 'Integer'</name>
<description>The amount of storage for a static symbol has reached or exceeded a value that was specified in a -size option (See Section 5.7, "Other Options").</description>
</rule>
<rule>
<key>813</key>
<configkey>813</configkey>
<priority>MINOR</priority>
<name>auto variable 'Symbol' in function 'Symbol' has size 'Integer'</name>
<description>The amount of storage for an auto symbol has reached or exceeded a value that was specified in a -size option (See Section 5.7, "Other Options").</description>
</rule>
<rule>
<key>814</key>
<configkey>814</configkey>
<priority>MINOR</priority>
<name>useless declaration</name>
<description>A tagless struct was declared without a declarator. For example: struct { int n; }; Such a declaration cannot very well be used.</description>
</rule>
<rule>
<key>815</key>
<configkey>815</configkey>
<priority>MINOR</priority>
<name>Arithmetic modification of unsaved pointer</name>
<description>An allocation expression (malloc, calloc, new) is not immediately assigned to a variable but is used as an operand in some expression. This would make it difficult to free the allocated storage. For example:
p = new X[n] + 2;
will elicit this message. A preferred sequence is:
q = new X[n]; p = q+2;
In this way the storage may be freed via the custodial pointer q.
Another example of a statement that will yield this message is:
p = new (char *) [n];
This is a gruesome blunder on the part of the programmer. It does NOT allocate an array of pointers as a novice might think. It is parsed as:
p = (new (char *)) [n];
which represents an allocation of a single pointer followed by an index into this 'array' of one pointer.</description>
</rule>
<rule>
<key>816</key>
<configkey>816</configkey>
<priority>MINOR</priority>
<name>Non-ANSI format specification</name>
<description>A non-standard format specifier was found in a format-processing function such as printf or scanf. Such a specifier could be unique to a particular compiler or could be a de facto standard but is not ANSI.</description>
</rule>
<rule>
<key>817</key>
<configkey>817</configkey>
<priority>MINOR</priority>
<name>Conceivably negative subscript (Integer) in operator 'String'</name>
<description>An integer whose value was conceivably negative was added to an array or to a pointer to an allocated area (allocated by malloc, operator new, etc.) This message is not given for pointers whose origin is unknown since a negative subscript is in general legal.
The addition could have occurred as part of a subscript operation or as part of a pointer arithmetic operation. The operator is denoted by String. The value of the integer is given by Integer.</description>
</rule>
<rule>
<key>818</key>
<configkey>818</configkey>
<priority>MINOR</priority>
<name>Pointer parameter 'Symbol' (Location) could be declared ptr to const</name>
<description>As an example:
int f( int *p ) { return *p; }
can be redeclared as:
int f( const int *p ) { return *p; }
Declaring a parameter a pointer to const offers advantages that a mere pointer does not. In particular, you can pass to such a parameter the address of a const data item. In addition it can offer better documentation.
Other situations in which a const can be added to a declaration are covered in messages 952, 953, 954 and 1764.</description>
</rule>
<rule>
<key>820</key>
<configkey>820</configkey>
<priority>MINOR</priority>
<name>Boolean test of a parenthesized assignment</name>
<description>A Boolean test was made on the result of an assignment and, moreover, the assignment was parenthesized. For example:
if ( (a = b) ) ... // Info 820
will draw this informational whereas
if ( a = b ) ... // Info 720
(i.e. the unparenthesized case) will, instead, draw Info 720. We, of course, do not count the outer parentheses required by the language that always accompany the if clause.
The reason for partitioning the messages in this fashion is to allow the programmer to adopt the convention, advanced by some compilers (in particular gcc), of always placing a redundant set of parentheses around any assignment that is to be tested. In this case you can suppress Info 820 (via -e820) while still enabling Info 720.</description>
</rule>
<rule>
<key>821</key>
<configkey>821</configkey>
<priority>MINOR</priority>
<name>Right hand side of assignment not parenthesized</name>
<description>An assignment operator was found having one of the following forms: a = b || c a = b && c a = b ? c : d
Moreover, the assignment appeared in a context where a value was being obtained. For example:
f( a = b ? c : d );
The reader of such code could easily confuse the assignment for a test for equality. To eliminate any such doubts we suggest parenthesizing the right hand side as in:
f( a = (b ? c : d) );</description>
</rule>
<rule>
<key>825</key>
<configkey>825</configkey>
<priority>MINOR</priority>
<name>control flows into case/default without -fallthrough comment</name>
<description>A common programming mistake is to forget a break statement between case statements of a switch. For example: case 'a': a = 0; case 'b': a++;
Is the fall through deliberate or is this a bug? To signal that this is intentional use the -fallthrough option within a lint comment as in: case 'a': a = 0; //lint -fallthrough case 'b': a++;
This message is similar to Warning 616 ("control flows into case/default") and is intended to provide a stricter alternative. Warning 616 is suppressed by any comment appearing between the case's. Thus, an accidental omission of a break can go undetected by the insertion of a neutral comment. This can be hazardous to well-commented programs.</description>
</rule>
<rule>
<key>826</key>
<configkey>826</configkey>
<priority>MINOR</priority>
<name>Suspicious pointer-to-pointer conversion (area too small)</name>
<description>A pointer was converted into another either implicitly or explicitly. The area pointed to by the destination pointer is larger than the area that was designated by the source pointer. For example:
long *f( char *p ) { return (long *) p; }</description>
</rule>
<rule>
<key>827</key>
<configkey>827</configkey>
<priority>MINOR</priority>
<name>Loop not reachable</name>
<description>A loop structure (for, while, or do) could not be reached. Was this an oversight? It may be that the body of the loop has a labeled statement and that the plan of the programmer is to jump into the middle of the loop through that label. It is for this reason that we give an Informational message and not the Warning (527) that we would normally deliver for an unreachable statement. But please note that jumping into a loop is a questionable practice in any regard.</description>
</rule>
<rule>
<key>828</key>
<configkey>828</configkey>
<priority>MINOR</priority>
<name>Semantics of function 'Name' copied to function 'Name'</name>
<description>A function with built-in semantics or user-defined semantics was #define'd to be some other function with a similar name formed by prepending or appending underscores. For example:
#define strcmp(a,b) __strcmp__(a,b)
will cause Info 828 to be issued. As the message indicates, the semantics will be automatically transferred to the new function.</description>
</rule>
<rule>
<key>829</key>
<configkey>829</configkey>
<priority>MINOR</priority>
<name>A +headerwarn option was previously issued for header 'Symbol</name>
<description>Some coding standards discourage or even prohibit the use of certain header files. PC-lint can guard against their use if we by activating the lint option +headerwarn(Symbol). Later, if the file is used, we will then issue this message.</description>
</rule>
<rule>
<key>830</key>
<configkey>830</configkey>
<priority>MINOR</priority>
<name>Location cited in prior message</name>
<description>Message 830 is a vehicle to convey in 'canonical form' the location information embedded within some other message. For example, consider the (somewhat simplified) message:
file x.c line 37: Declaration for 'x' conflicts with line 22
This contains the location ("line 22") embedded in the text of the message. Embedded location information is not normally understood by editors and IDE's (Interactive Development Environments) which can only position to the nominal location (line 37 in this example). By adding this additional message with the nominal location of line 22 the user can, by stepping to the next message and, in this case, see what the 'conflict' is all about. This message and message 831 below do not follow the ordinary rules for message suppression. If they did then when the option -w2 was employed to turn the warning level down to 2 these messages (at level 3) would also vanish. Instead they continue to function as expected. To inhibit them you need to explicitly turn them off using one of: -e830 -e831 They may be restored via +e830 and +e831; they state of suppression can be saved and restored via the -save -restore options. Options such as -e8* and -e{831} will have no effect.</description>
</rule>
<rule>
<key>831</key>
<configkey>831</configkey>
<priority>MINOR</priority>
<name>Reference cited in prior message</name>
<description>Message 831 is similar to message 830 in that it is a vehicle to convey in 'canonical form' location information embedded within some other message. In the case of Info 831 the information is 'Reference' information. This is a sequence of 1 or more locations that support a particular message. For example, consider the (somewhat simplified) message:
file y.c line 701: Possible divide by 0 [Reference: file z.c lines 22, 23]
Accompanying this message will be two Info 831 messages, one for each of the references cited in the message. Without this it would be a relatively tedious matter to locate each one of the references to determine just why there is a potential divide by 0. With these additional messages, editors and IDE's can automatically position the focus of editing to the nominal locations of the message.</description>
</rule>
<rule>
<key>832</key>
<configkey>832</configkey>
<priority>MINOR</priority>
<name>Parameter 'Symbol' not explicitly declared, int assumed</name>
<description>In an old-style function definition a parameter was not explicitly declared. To illustrate: void f( n, m ) int n; { ...
This is an example of an old-style function definition with n and m the parameters. n is explicitly declared and m is allowed to default to int. An 832 will be issued for m.</description>
</rule>
<rule>
<key>833</key>
<configkey>833</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' is typed differently (String) in another module, Location,</name>
<description>Two objects, functions or definials are typed differently in two different modules. This is a case where the difference is legal but may cause confusion on the part of program maintenance.</description>
</rule>
<rule>
<key>834</key>
<configkey>834</configkey>
<priority>MINOR</priority>
<name>Operator 'Name' followed by operator 'Name' is confusing. Use parentheses.</name>
<description>Some combinations of operators seem to be confusing. For example
a = b - c - d; a = b - c + d; a = b / c / d; a = b / c * d;
tend to befuddle the reader. To reduce confusion we recommend using parentheses to make the association of these operators explicit. For example:
a = (b - c) - d; a = (b - c) + d; a = (b / c) / d; a = (b / c) * d;
in place of the above.</description>
</rule>
<rule>
<key>835</key>
<configkey>835</configkey>
<priority>MINOR</priority>
<name>A zero has been given as [left/right] argument to operator 'Name'</name>
<description>A 0 has been provided as an operand to an arithmetic operator. The name of the operator is provided in the message as well as the side of the operator (left or right) that had the unusual value. For example: n = n + 0 - m; will produce a message that the right hand operand of operator '+' is zero.
In general the operators examined are the binary operators: + - * / % | & ^ << >> and the unary operators - and +.
An enumeration constant whose value is 0 is permitted with operators: + - >> << Otherwise a message is issued. For example: enum color { red, blue = red+100, /* ok */ green= red*0x10 /* 835 */ }; The assignment operators that have an arithmetic or bitwise component, such as |=, are also examined. The message given is equivalent to that given with the same operator without the assignment component.</description>
</rule>
<rule>
<key>836</key>
<configkey>836</configkey>
<priority>MINOR</priority>
<name>Conceivable access of pointer pointing Integer bytes past nul character by operator 'String'</name>
<description>A situation was detected where it appears remotely possible that a buffer is being accessed beyond the (nul-terminated) string that was placed in the buffer. An example of accessing beyond the nul character is shown in the example below: char buf[20]; int k = 4; strcpy( buf, "a" ); if( buf[k] == 'a' ) ... // legal but suspect In this particular case the access would be deemed 'likely' and a different but related message (Warning 448 in Section 13.3) would have been issued. This message (836) could be issued if there were some intervening code involving k. See also Warning 690 in Section 13.3.</description>
</rule>
<rule>
<key>838</key>
<configkey>838</configkey>
<priority>MINOR</priority>
<name>Previously assigned value to variable 'Symbol' has not been used</name>
<description>An assignment statement was encountered that apparently obliterated a previously assigned value that had never had the opportunity of being used. For example, consider the following code fragment: y = 1; if( n > 0 ) y = 2; y = 4; // Info 838 ... Here we can report that the assignment of 4 to y obliterates previously assigned values that were not used. We, of course, cannot report anything unusual about the assignment of 2. This will assign over a prior value of 1 that so far had not been used but the existence of an alternative path means that the value of 1 can still be employed later in the code and is accepted for the time being as reasonable. It is only the final assignment that raises alarm bells. See also Warning 438 in Section 13.3.</description>
</rule>
<rule>
<key>839</key>
<configkey>839</configkey>
<priority>MINOR</priority>
<name>Storage class of symbol 'Symbol' assumed static (Location)</name>
<description>A declaration for a symbol that was previously declared static in the same module was found without the 'static' specifier. For example: static void f(); extern void f(); // Info 839 void f() {} // Info 839 By the rules of the language 'static' wins and the symbol is assumed to have internal linkage. This could be the definition of a previously declared static function (as in line 3 of the above example) in which case by adding the static specifier you will inhibit this message. This could also be a redeclaration of either a function or a variable (as in line 2 of the above example) in which case the redeclaration is redundant.</description>
</rule>
<rule>
<key>840</key>
<configkey>840</configkey>
<priority>MINOR</priority>
<name>Use of nul character in a string literal</name>
<description>A nul character was found in a string literal. This is legal but suspicious and may have been accidental. This is because a nul character is automatically placed at the end of a string literal and because conventional usage and most of the standard library's string functions ignore information past the first nul character.</description>
</rule>
<rule>
<key>843</key>
<configkey>843</configkey>
<priority>MINOR</priority>
<name>Variable 'Symbol' (Location) could be declared as const</name>
<description>A variable of static storage duration is initialized but never modified thereafter. Was this an oversight? If the intent of the programmer is to not modify the variable, it could and should be declared as const. See [30, Item 3] in Section 14. Added Bibliography and message 844.</description>
</rule>
<rule>
<key>844</key>
<configkey>844</configkey>
<priority>MINOR</priority>
<name>Pointer variable 'Symbol' (Location) could be declared as pointing to const</name>
<description>The data pointed to by a pointer of static storage duration is never changed (at least not through that pointer). It therefore would be better if the variable were typed pointer to const. See [30, Item 3] in Section 14. Added Bibliography and message 843.</description>
</rule>
<rule>
<key>845</key>
<configkey>845</configkey>
<priority>MINOR</priority>
<name>The [left/right] argument to operator 'Name' is certain to be 0</name>
<description>An operand that can be deduced to always be 0 has been presented to an arithmetic operator in a context that arouses suspicion. The name of the operator is provided in the message as well as the side of the operator (left or right) that had the unusual value. For example: n = 0; k = m & n; will produce a message that the right hand operand of operator '&' is certain to be zero.
The operands examined are the right hand sides of operators + - | || the left hand sides of operators / % and both sides of operators * & << >> && The reason that the left hand side of operator + (and friends) is not examined for zero is that zero is the identity operation for those operators and hence is often used as an initializing value. For example: sum = 0; for( ... ) sum = sum + what_ever; // OK, no message The message is not issued for arithmetic constant zeros. Info 835 in Section 13.4 is issued in that instance.
The message is also suspended when the expression has side-effects. For example: i = 0; buf[i++] = 'A'; We don't consider it reasonable to force the programmer to write: buf[0] = 'A'; i = 1;</description>
</rule>
<rule>
<key>846</key>
<configkey>846</configkey>
<priority>MINOR</priority>
<name>Signedness of bit-field is implementation defined</name>
<description>A bit-field was detected having the form: int a:5; Most bit fields are more useful when they are unsigned. If you want to have a signed bit field you must explicitly indicate this as follows: signed int a:5; The same also holds for typedef's. For example, typedef int INT; typedef signed int SINT; struct { INT a:16; // Info 846 SINT b:16; // OK }: It is very unusual in C or C++ to distinguish between signed int and just plain int. This is one of those rare cases.</description>
</rule>
<rule>
<key>847</key>
<configkey>847</configkey>
<priority>MINOR</priority>
<name>Thread 'Symbol' has unprotected call to thread unsafe function 'Symbol'</name>
<description>A thread named in the message makes an unprotected call (i.e., outside of a critical section) on the function named in the message. The function had previously been identified as thread unsafe. See Section 8. Mult-thread Support for a definition of the terms: unprotected and thread unsafe.
This is not necessarily an error. Most thread unsafe functions may be called outside of critical sections provided no other thread is making such a call. There are other messages (at the Warning level) that will be issued when some other thread is also calling the same function, so it would normally be safe to suppress this message.</description>
</rule>
<rule>
<key>848</key>
<configkey>848</configkey>
<priority>MINOR</priority>
<name>Worst case function for stack usage: String</name>
<description>This message, issued at global wrap-up, will report on the function that requires the most stack. The stack required consists of the amount of auto storage the function requires plus the amounts required in any chain of functions called. The worst case chain is always reported.
To obtain a report of all the function use the option -ok(filename).
Reasonable allowances are made for function call overhead and the stack requirements of external functions. These assumptions can be controlled via the -stack option.
If recursion is detected it will be reported here as this is considered worse than any finite case. The next worse case is that the stack can't be determined because a function makes a call through a function pointer. The function is said to be non-deterministic. If neither if these conditions prevail, the function that heads the worst case chain of calls will be reported upon.
The message will normally provide you with the name of a called function. If the function is recursive this will provide you with the first call of a recursive loop. To determine the full loop, use option -ok(filename) which will contain a record for each function for which a definition was found. You will be able to follow the chain of calls to determine the recursive path.
If you can assure yourself through code analysis that there is an upper bound to the amount of stack utilized by some recursive function then you can employ the -stack option to specify this bound. The function will no longer be considered recursive but rather finite. In this way, possibly through a sequence of options, you can progressively eliminate apparent recursion and in that way arrive at a safe upper bound for stack usage. Similar considerations apply for non-deterministic functions.</description>
</rule>
<rule>
<key>849</key>
<configkey>849</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' has same enumerator value 'String' as enumerator 'Symbol'</name>
<description>Two enumerators have the same value. For example: enum colors { red, blue, green = 1 }; will elicit this informational message. This is not necessarily an error and you may want to suppress this message for selected enumerators.</description>
</rule>
<rule>
<key>850</key>
<configkey>850</configkey>
<priority>MINOR</priority>
<name>for loop index variable 'Symbol' whose type category is 'String' modified in body of the for loop that began at 'String'</name>
<description>Note: This message is delivered after the for loop has been completed.
A for loop with an identifiable loop index variable was programmed in such a way that the loop body also modifies the index variable. For example: for( i = 0; i < 100; i++ ) { a[i++] = 0; } In general it is better to restrict modifications to for loop index variables to the for clause if at all possible. If this is not possible, you can prefix the for loop with an appropriate lint comment such as: /*lint -e{850} i is modified in the body of the for loop */ The message is parameterized with a type category which is one of:
integral some form of integer float some form of floating point number string some form of char * including wide char pointer some form of pointer other than string enumeration an enumeration of some kind unclassified none of the above
This will allow you to be more selective in the delivery of messages because you may suppress or enable messages according to these classifications. For example: -e850 +estring(850,integral) +estring(850,float) will enable Info 850 for integrals or for floats but not for other forms of loop variables.</description>
</rule>
<rule>
<key>864</key>
<configkey>864</configkey>
<priority>MINOR</priority>
<name>Expression involving variable 'Symbol' possibly depends on order of evaluation</name>
<description>The variable cited in the message is either passed to a reference that is not a const reference or its address is passed to a pointer that is not a pointer to const. Hence the variable is potentially modified by the function. If the same variable is used elsewhere in the same expression, then the result may depend on the order of evaluation of the expression. For example: int g( int ); int h( int & ); int f( int k ) { return g(k) + h(k); // Info 864 } Here the compiler is free to evaluate the call to g() first with the original value of k and then call h() where k gets modified. Alternatively, it can, with equal validity, call h() first in which case the value passed to g() would be the new value.
The object being modified could be the implicit argument (the this argument) to a member function call. For example: void f( int, int ); class X { public: int bump(); int k; }; ... X x; f( x.bump(), x.bump() ); // Info 864 Here the message states that the expression involving object x possibly depends on the order of evaluation. x is an implicit argument (by reference) to the bump() member function. If the member function bump() were declared const then the message would not have been emitted.
(See also 11.1 Order of Evaluation in the manual and Warning 564).</description>
</rule>
<rule>
<key>866</key>
<configkey>866</configkey>
<priority>MINOR</priority>
<name>Unusual use of 'String' in argument to sizeof</name>
<description>An expression used as an argument to sizeof() counts as "unusual" if it is not a constant, a symbol, a function call, a member access, a subscript operation (with indices of zero or one), or a dereference of the result of a symbol, scoped symbol, array subscript operation, or function call. Also, since unary '+' could legitimately be used to determine the size of a promoted expression, it does not fall under the category of "unusual". Example: char A[10]; unsigned end = sizeof(A - 1); // 866; Programmer probably meant // 'sizeof(A) - 1' size_of_promoted_char = sizeof(+A[0]); // '+' makes a difference here size_t s1 = sizeof( end+1 ); // 866: use +end to get promoted type size_t s2 = sizeof( +(end+1) ); // OK, we won't complain struct B *p; // B is some POD. B b1;
memcpy( p, &b1, sizeof(&b1) ); // 866; intended to take sizeof(b1)
size_t s3 = sizeof(A[0]); // OK, get the size of an element. size_t s4 = sizeof(A[2]); // 866; Not incorrect, but ... // unusual in a sizeof().</description>
</rule>
<rule>
<key>867</key>
<configkey>867</configkey>
<priority>MINOR</priority>
<name>Unrecognized pragma 'Name' will be ignored</name>
<description>The first identifier after #pragma is considered the name of the pragma. If the name is unrecognized then the remainder of the line is ignored. Since the purpose of #pragma is to allow for compiler-dependent communication it is not really expected that all pragmas will be understood by all third-party processors of the code. Thus, this message does not necessarily indicate that there is anything wrong and could easily be supressed entirely.
Moreover, if the pragma occurs in a libary header this message would not normally be issued because the option -wlib(1) would be in effect (this option is present in all of our compiler option files).
But if the pragma occurs in user code then it should be examined to see if there is something there that might interest a lint processor. There are a variety of facilities to deal with pragmas; in particular, they can be mapped into languistic constructs or lint options or both. See 3.5 pragmas push_macro and pop_macro and 3.6 Casting pragmas as macros.</description>
</rule>
<rule>
<key>900</key>
<configkey>900</configkey>
<priority>INFO</priority>
<name>Successful completion, 'Integer' messages produced</name>
<description>This message exists to provide some way of ensuring that an output message is always produced, even if there are no other messages. This is required for some windowing systems. For this purpose use the option +e900.</description>
</rule>
<rule>
<key>904</key>
<configkey>904</configkey>
<priority>INFO</priority>
<name>Return statement before end of function 'Symbol'</name>
<description>A return statement was found before the end of a function definition. Many programming standards require that functions contain a single exit point located at the end of the function. This can enhance readability and may make subsequent modification less error prone.</description>
</rule>
<rule>
<key>905</key>
<configkey>905</configkey>
<priority>INFO</priority>
<name>Non-literal format specifier used (with arguments)</name>
<description>A printf/scanf style function received a non-literal format specifier but, unlike the case covered by Warning 592 in Section 13.3 the function also received additional arguments. E.g. char *fmt; int a, b; ... printf( fmt, a, b ); Variable formats represent a very powerful feature of C/C++ but they need to be used judiciously. Unlike the case covered by Warning 592, this case cannot be easily rewritten with an explicit visible format. But this Elective Note can be used to examine code with non-literal formats to make sure that no errors are present and that the formats themselves are properly constructed and contain no user-provided data. See also Warning 592 in Section 13.3</description>
</rule>
<rule>
<key>909</key>
<configkey>909</configkey>
<priority>INFO</priority>
<name>Implicit conversion from Type to bool</name>
<description>A non-bool was tested as a Boolean. For example, in the following function: int f(int n) { if( n ) return n; else return 0; }
the programmer tests 'n' directly rather than using an explicit Boolean expression such as 'n != 0'. Some shops prefer the explicit test.</description>
</rule>
<rule>
<key>910</key>
<configkey>910</configkey>
<priority>INFO</priority>
<name>Implicit conversion (Context) from 0 to pointer</name>
<description>A pointer was assigned (or initialized) with a 0. Some programmers prefer other conventions such as NULL or nil. This message will help such programmers root out cavalier uses of 0. This is relatively easy in C since you can define NULL as follows:
#define NULL (void *)0
However, in C++, a void* cannot be assigned to other pointers without a cast. Instead, assuming that NULL is defined to be 0, use the option:
--emacro((910),NULL)
This will inhibit message 910 in expressions which use NULL. This method will also work in C.
Both methods assume that you expressly turn on this message with a +e910 or equivalent.</description>
</rule>
<rule>
<key>911</key>
<configkey>911</configkey>
<priority>INFO</priority>
<name>Implicit expression promotion from Type to Type</name>
<description>Notes whenever a sub-integer expression such as a char, short, enum, or bit-field is promoted to int for the purpose of participating in some arithmetic operation or function call.</description>
</rule>
<rule>
<key>912</key>
<configkey>912</configkey>
<priority>INFO</priority>
<name>Implicit binary conversion from Type to Type</name>
<description>Notes whenever a binary operation (other than assignment) requires a type balancing. A smaller range type is promoted to a larger range type. For example: 3 + 5.5 will trigger such a message because int is converted to double.</description>
</rule>
<rule>
<key>913</key>
<configkey>913</configkey>
<priority>INFO</priority>
<name>Implicit adjustment of expected argument type from Type to Type</name>
<description>Notes whenever an old-style function definition contains a sub-integer or float type. For example:
int f( ch, x ) char ch; float x; { ...
contains two 913 adjustments.</description>
</rule>
<rule>
<key>914</key>
<configkey>914</configkey>
<priority>INFO</priority>
<name>Implicit adjustment of function return value from Type to Type</name>
<description>Notes whenever the function return value is implicitly adjusted. This message is given only for functions returning arrays.</description>
</rule>
<rule>
<key>915</key>
<configkey>915</configkey>
<priority>INFO</priority>
<name>Implicit conversion (Context) Type to Type</name>
<description>Notes whenever an assignment, initialization or return implies an arithmetic conversion (Context specifies which).</description>
</rule>
<rule>
<key>916</key>
<configkey>916</configkey>
<priority>INFO</priority>
<name>Implicit pointer assignment conversion (Context)</name>
<description>Notes whenever an assignment, initialization or return implies an implicit pointer conversion (Context specifies which).</description>
</rule>
<rule>
<key>917</key>
<configkey>917</configkey>
<priority>INFO</priority>
<name>Prototype coercion (Context) Type to Type</name>
<description>Notes whenever an implicit arithmetic conversion takes place as the result of a prototype. For example:
double sqrt(double); ... sqrt(3); ...
will elicit this message because 3 is quietly converted to double.</description>
</rule>
<rule>
<key>918</key>
<configkey>918</configkey>
<priority>INFO</priority>
<name>Prototype coercion (Context) of pointers</name>
<description>Notes whenever a pointer is implicitly converted because of a prototype. Because of prototype conversion, near pointers will otherwise be silently mapped into far pointers. far pointers mapped into near pointers also generate message 619.</description>
</rule>
<rule>
<key>919</key>
<configkey>919</configkey>
<priority>INFO</priority>
<name>Implicit conversion (Context) Type to Type</name>
<description>A lower precision quantity was assigned to a higher precision variable as when an int is assigned to a double.</description>
</rule>
<rule>
<key>920</key>
<configkey>920</configkey>
<priority>INFO</priority>
<name>Cast from Type to void</name>
<description>A cast is being made from the given type to void.</description>
</rule>
<rule>
<key>921</key>
<configkey>921</configkey>
<priority>INFO</priority>
<name>Cast from Type to Type</name>
<description>A cast is being made from one integral type to another.</description>
</rule>
<rule>
<key>922</key>
<configkey>922</configkey>
<priority>INFO</priority>
<name>Cast from Type to Type</name>
<description>A cast is being made to or from one of the floating types (float, double, long double).</description>
</rule>
<rule>
<key>923</key>
<configkey>923</configkey>
<priority>INFO</priority>
<name>Cast from Type to Type</name>
<description>A cast is being made either from a pointer to a non-pointer or from a non-pointer to a pointer.</description>
</rule>
<rule>
<key>924</key>
<configkey>924</configkey>
<priority>INFO</priority>
<name>Cast from Type to Type</name>
<description>A cast is being made from a struct or a union. If the cast is not to a compatible struct or union error 69 is issued.</description>
</rule>
<rule>
<key>925</key>
<configkey>925</configkey>
<priority>INFO</priority>
<name>Cast from pointer to pointer</name>
<description>A cast is being made to convert one pointer to another such that one of the pointers is a pointer to void. Such conversions are considered harmless and normally do not even need a cast.</description>
</rule>
<rule>
<key>926</key>
<configkey>926</configkey>
<priority>INFO</priority>
<name>Cast from pointer to pointer</name>
<description>A cast is being made to convert a char pointer to a char pointer (one or both of the char's may be unsigned). This is considered a 'safe' cast.</description>
</rule>
<rule>
<key>927</key>
<configkey>927</configkey>
<priority>INFO</priority>
<name>Cast from pointer to pointer</name>
<description>A cast is being made to convert a char (or unsigned char) pointer to a non-char pointer. char pointers are sometimes implemented differently from other pointers and there could be an information loss in such a conversion.</description>
</rule>
<rule>
<key>928</key>
<configkey>928</configkey>
<priority>INFO</priority>
<name>Cast from pointer to pointer</name>
<description>A cast is being made from a non-char pointer to a char pointer. This is generally considered to be a 'safe' conversion.</description>
</rule>
<rule>
<key>929</key>
<configkey>929</configkey>
<priority>INFO</priority>
<name>Cast from pointer to pointer</name>
<description>A cast is being made to convert one pointer to another that does not fall into one of the classifications described in 925 through 928 above. This could be nonportable on machines that distinguish between pointer to char and pointer to word. Consider casting a pointer to pointer to char to a pointer to pointer to word. The indirect bit pattern remains unchanged.</description>
</rule>
<rule>
<key>930</key>
<configkey>930</configkey>
<priority>INFO</priority>
<name>Cast from Type to Type</name>
<description>A cast is being made to or from an enumeration type.</description>
</rule>
<rule>
<key>931</key>
<configkey>931</configkey>
<priority>INFO</priority>
<name>Both sides have side effects</name>
<description>Indicates when both sides of an expression have side-effects. An example is n++ + f(). This is normally benign. The really troublesome cases such as n++ + n are caught via Warning 564.</description>
</rule>
<rule>
<key>932</key>
<configkey>932</configkey>
<priority>INFO</priority>
<name>Passing near pointer to library function '(Symbol)' (Context)</name>
<description>A source of error in Windows programming is to pass a near pointer to a library function. If the library is a DLL library, then in supplying the missing segment, the library would assume its own data segment which would probably be wrong. See also messages 933 and 934.</description>
</rule>
<rule>
<key>933</key>
<configkey>933</configkey>
<priority>INFO</priority>
<name>Passing near pointer to far function (Context)</name>
<description>A source of error in Windows programming is to pass a near pointer to a DLL function. Most Microsoft functions in DLLs are declared with the far modifier. Hence this can be tentatively used as a discriminant to decide that a pointer is too short. An advantage that this Note has over 932 is that it can catch functions designated only by pointer. Also you may be using libraries that are not DLLs and that share the same DS segment. In this case, 932 may produce too many superfluous messages. See also message 934.</description>
</rule>
<rule>
<key>934</key>
<configkey>934</configkey>
<priority>INFO</priority>
<name>Taking address of near auto variable 'Symbol' (Context)</name>
<description>A source of error in writing DLL libraries is that the stack segment may be different from the data segment. In taking the address of a near data object only the offset is obtained. In supplying the missing segment, the compiler would assume the data segment which could be wrong. See also messages 932 and 933.</description>
</rule>
<rule>
<key>935</key>
<configkey>935</configkey>
<priority>INFO</priority>
<name>int within struct</name>
<description>This Note helps to locate non-portable data items within struct's. If instead of containing int's and unsigned int's, a struct were to contain short's and long's then the data would be more portable across machines and memory models. Note that bit fields and union's do not get complaints.</description>
</rule>
<rule>
<key>936</key>
<configkey>936</configkey>
<priority>INFO</priority>
<name>old-style function definition for function 'Symbol'</name>
<description>An "old-style" function definition is one in which the types are not included between parentheses. Only names are provided between parentheses with the type information following the right parenthesis. This is the only style allowed by K&R.</description>
</rule>
<rule>
<key>937</key>
<configkey>937</configkey>
<priority>INFO</priority>
<name>old-style function declaration for function 'Symbol'</name>
<description>An "old-style" function declaration is one which does not have type information for its arguments.</description>
</rule>
<rule>
<key>938</key>
<configkey>938</configkey>
<priority>INFO</priority>
<name>parameter 'Symbol' not explicitly declared</name>
<description>In an "old-style" function definition it is possible to let a function parameter default to int by simply not providing a separate declaration for it.</description>
</rule>
<rule>
<key>939</key>
<configkey>939</configkey>
<priority>INFO</priority>
<name>return type defaults to int for function 'Symbol'</name>
<description>A function was declared without an explicit return type. If no explicit storage class is given, then Informational 745 is also given provided the Deduce Return mode flag (fdr) is off. This is meant to catch all cases.</description>
</rule>
<rule>
<key>940</key>
<configkey>940</configkey>
<priority>INFO</priority>
<name>omitted braces within an initializer</name>
<description>An initializer for a subaggregate does not have braces. For example:
int a[2][2] = { 1, 2, 3, 4 };
This is legal C but may violate local programming standards. The worst violations are covered by Warning 651.</description>
</rule>
<rule>
<key>941</key>
<configkey>941</configkey>
<priority>INFO</priority>
<name>Result 0 due to operand(s) equaling 0 in operation 'String'</name>
<description>The result of a constant evaluation is 0 owing to one of the operands of a binary operation being 0. This is less severe than Info 778 wherein neither operand is 0. For example, expression (2&1) yields a 778 whereas expression (2&0) yields a 941.</description>
</rule>
<rule>
<key>942</key>
<configkey>942</configkey>
<priority>INFO</priority>
<name>Possibly truncated addition promoted to float</name>
<description>An integral expression (signed or unsigned) involving addition or subtraction is converted to a floating point number. If an overflow occurred, information would be lost. See also messages 647, 776 and 790.</description>
</rule>
<rule>
<key>943</key>
<configkey>943</configkey>
<priority>INFO</priority>
<name>Too few initializers for aggregate 'Symbol'</name>
<description>The initializer {0} was used to initialize an aggregate of more than one item. Since this is a very common thing to do it is given a separate message number which is normally suppressed. See 785 for more flagrant abuses.</description>
</rule>
<rule>
<key>944</key>
<configkey>944</configkey>
<priority>INFO</priority>
<name>[left/right/] argument for operator 'String' always evaluates to [True/False]</name>
<description>The indicated operator (given by String has an argument that appears to always evaluate to either 'True' or 'False' (as indicated in the message). This is given for Boolean operators (||and && and for Unary operator !) and information is gleaned from a variety of sources including prior assignment statements and initializers. Compare this with message 506 which is based on testing constants or combinations of constants.</description>
</rule>
<rule>
<key>945</key>
<configkey>945</configkey>
<priority>INFO</priority>
<name>Undefined struct used with extern</name>
<description>Some compilers refuse to process declarations of the form:
extern struct X s;
where struct X is not yet defined. This note can alert a programmer porting to such platforms.</description>
</rule>
<rule>
<key>946</key>
<configkey>946</configkey>
<priority>INFO</priority>
<name>Relational or subtract operator applied to pointers</name>
<description>A relational operator (one of >, >=, <, <=) or the subtract operator has been applied to a pair of pointers. The reason this is of note is that when large model pointers are compared (in one of the four ways above) or subtracted, only the offset portion of the pointers is subject to the arithmetic. It is presumed that the segment portion is the same. If this presumption is not accurate then disaster looms. By enabling this message you can focus in on the potential trouble spots.</description>
</rule>
<rule>
<key>947</key>
<configkey>947</configkey>
<priority>INFO</priority>
<name>Subtract operator applied to pointers</name>
<description>An expression of the form p - q was found where both p and q are pointers. This is of special importance in cases where the maximum pointer can overflow the type that holds pointer differences. For example, suppose that the maximum pointer is 3 Gigabytes -1, and that pointer differences are represented by a long, where the maximum long is 2 Gigabytes -1. Note that both of these quantities fit within a 32 bit word. Then subtracting a small pointer from a very large pointer will produce an apparent negative value in the long representing the pointer difference. Conversely, subtracting a very large pointer from a small pointer can produce a positive quantity.
The alert reader will note that a potential problem exists whenever the size of the type of a pointer difference equals the size of a pointer. But the problem doesn't usually manifest itself since the highest pointer values are usually less than what a pointer could theoretically hold. For this reason, the message cannot be given automatically based on scalar types and hence has been made an Elective Note.
Compare this Note with that of 946 which was designed for a slightly different pointer difference problem.</description>
</rule>
<rule>
<key>948</key>
<configkey>948</configkey>
<priority>INFO</priority>
<name>Operator 'String' always evaluates to [True/False]</name>
<description>The operator named in the message is one of four relational operators or two equality operators in the list: > >= < <= == != The arguments are such that it appears that the operator always evaluates to either True or to False (as indicated in the message). This is similar to message 944. Indeed there is some overlap with that message. Message 944 is issued in the context where a Boolean is expected (such as the left hand side of a ? operator) but may not involve a relational operator. Message 948 is issued in the case of a relational (or equality) operator but not necessarily in a situation that requires a Boolean.</description>
</rule>
<rule>
<key>950</key>
<configkey>950</configkey>
<priority>INFO</priority>
<name>Non-ANSI reserved word or construct: 'Symbol'</name>
<description>Symbol is either a reserved word that is non-ANSI or a construct (such as the // form of comment in a C module). This Elective Note is enabled automatically by the -A option. If these messages are occurring in a compiler or library header file over which you have no control, you may want to use the option -elib(950). If the reserved word is one which you want to completely disable, then use the option -rw(Word).</description>
</rule>
<rule>
<key>951</key>
<configkey>951</configkey>
<priority>INFO</priority>
<name>Pointer to incomplete type 'Symbol' employed in operation</name>
<description>A pointer to an incomplete type (for example, struct X where struct X has not yet been defined in the current module) was employed in an assignment or in a comparison (for equality) operator. For example, suppose a module consisted only of the following function: struct A * f(struct A *p ) { return p; }
Since struct A had not been defined, this message will be issued. Such employment is permitted by the standard but is not permitted by all C compilers. If you want to deploy your application to the maximum number of platforms you should enable this Elective Note.</description>
</rule>
<rule>
<key>952</key>
<configkey>952</configkey>
<priority>INFO</priority>
<name>Parameter 'Symbol' (Location) could be declared const</name>
<description>A parameter is not modified by a function. For example:
int f( char *p, int n ) { return *p = n; }
can be redeclared as:
int f( char * const p, const int n ) { return *p = n; }
There are few advantages to declaring an unchanging parameter a const. It signals to the person reading the code that a parameter is unchanging, but, in the estimate of most, reduces legibility. For this reason the message has been given an Elective Note status.
However, there is a style of programming that encourages declaring parameters const. For the above example, this style would declare f as
int f( char * p, int n);
and would use the const qualifier only in the definition. Note that the two forms are compatible according to the standard. The declaration is considered the interface specification where the const's do not matter. The const's do matter in the definition of the function which is considered the implementation. Message 952 could be used to support this style.
Marking a parameter as const does not affect the type of argument that can be passed to the parameter. In particular, it does not mean that only const arguments may be passed. This is in contrast to declaring a parameter as pointer to const or reference to const. For these situations, Informational messages are issued (818 and 1764 respectively) and these do affect the kinds of arguments that may be passed. See also messages 953 and 954.</description>
</rule>
<rule>
<key>953</key>
<configkey>953</configkey>
<priority>INFO</priority>
<name>Variable 'Symbol' (Location) could be declared as const</name>
<description>A local variable (either static or auto) is initialized but never modified thereafter. Such a variable could be declared const. One advantage in making such a declaration is that it can furnish a clue to the program reader that the variable is unchanging. In the case of static data it can mean that the data is ROM'able. Other situations in which a const can be added to a declaration are covered in messages 818, 952, 954 and 1764.</description>
</rule>
<rule>
<key>954</key>
<configkey>954</configkey>
<priority>INFO</priority>
<name>Pointer variable 'Symbol' (Location) could be declared as pointing to a const</name>
<description>The data pointed to by a pointer is never changed (at least not through that pointer). It may therefore be better, or at least more descriptive, if the variable were typed pointer to const. For example: { char *p = "abc"; for( ; *p; p++ ) print(*p); }
can be redeclared as: { const char *p = "abc"; for( ; *p; p++ ) print(*p); }
It is interesting to contrast this situation with that of pointer parameters. The latter is given Informational status (818) because it has an effect of enhancing the set of pointers that can be passed into a function. Other situations in which a const can be added to a declaration are covered in messages 952, 953 and 1764.</description>
</rule>
<rule>
<key>955</key>
<configkey>955</configkey>
<priority>INFO</priority>
<name>Parameter name missing from prototype for function 'Symbol'</name>
<description>In a function declaration a parameter name is missing. For example:
void f(int);
will raise this message. This is perfectly legal but misses an opportunity to instruct the user of a library routine on the nature of the parameter. For example:
void f(int count);
would presumably be more meaningful. [27, Rule 34].
This message is not given for function definitions, only function declarations.</description>
</rule>
<rule>
<key>956</key>
<configkey>956</configkey>
<priority>INFO</priority>
<name>Non const, non volatile static or external variable 'Symbol'</name>
<description>This check has been advocated by programmers whose applications are multi-threaded. Software that contains modifiable data of static duration is often non-reentrant. That is, two or more threads cannot run the code concurrently. By 'static duration' we mean variables declared static or variables declared external to any function. For example: int count = 0; void bump() { count++; } void get_count() { return count; }
If the purpose is to obtain a count of all the bump()'s by a given thread then this program clearly will not do since the global variable count sums up the bump()'s from all the threads. Moreover, if the purpose of the code is to obtain a count of all bump()'s by all threads, it still may contain a subtle error (depending on the compiler and the machine). If it is possible to interrupt a thread between the access of count and the subsequent store, then two threads that are bump()'ing at the same time, may register an increase in the count by just one.
Please note that not all code is intended to be re-entrant. In fact most programs are not designed that way and so this Elective Note need not be enabled for the majority of programs. If the program is intended to be re-entrant, all uses of non-const static variables should be examined carefully for non-reentrant properties.</description>
</rule>
<rule>
<key>957</key>
<configkey>957</configkey>
<priority>INFO</priority>
<name>Function 'Symbol' defined without a prototype in scope</name>
<description>A function was defined without a prototype in scope. It is usually good practice to declare prototypes for all functions in header files and have those header files checked against the definitions of the function to assure that they match.
If you are linting all the files of your project together such cross checking will be done in the natural course of things. For this reason this message has been given a relatively low urgency of Elective Note.</description>
</rule>
<rule>
<key>958</key>
<configkey>958</configkey>
<priority>INFO</priority>
<name>Padding of Integer byte(s) is required to align member on Integer byte boundary</name>
<description>This message is given whenever padding is necessary within a struct to achieve a required member alignment. Consider: struct A { char c; int n; }; Assuming that int must be aligned on a 4-byte boundary and assuming the size of a char to be 1, then this message will be issued indicating that there will be a padding of 3 bytes.
The alignment requirements vary with the compiler, the machine and, sometimes, compiler options. When separately compiled programs need to share data at the binary level it helps to remove any artifically created padding from any of the structures that may be shared.</description>
</rule>
<rule>
<key>959</key>
<configkey>959</configkey>
<priority>INFO</priority>
<name>Nominal struct size (Integer bytes) is not an even multiple of the maximum member alignment (Integer bytes)</name>
<description>The alignment of a structure (or union) is equal to the maximum alignment of any of its members. When an array of structures is allocated, the compiler ensures that each structure is allocated at an address with the proper alignment. This will require padding if the size of the structure is not an even multiple of its maximum alignment. For example: struct A { int n; char ch; } a[10]; Assuming the size and alignment of int is 4 then the size of each struct is 5 but its alignment is 4. As a result each struct in the array will be padded with 3 bytes.
Alignment can vary with the compiler and the machine. If binary data is to be shared by separately compiled modules, it is safer to make sure that all shared structures and unions are explicitly padded.</description>
</rule>
<rule>
<key>960</key>
<configkey>960</configkey>
<priority>INFO</priority>
<name>Violates MISRA Year Required Rule Name, String</name>
<description>MISRA is the "Guidelines for the use of the C Language in Vehicle Based Software". [10] The first version of the MISRA Standard was released in 1998 and the second in 2004. Lint references the rules from each version of the Standard using integers for 1998 and in decimal form for 2004, as per the Standard numbering style.
The list of required checks made for both MISRA 1998 and 2004 are:
(Rule 19/7.1) Octal constant used. (Rule 32/9.3) Should initialize either all enum members or only the first.
(Rule 33/12.4) Side effects on right hand side of logical operator.
(Rule 42/12.10) Comma operator used outside of 'for' expression.
(Rule 54/14.3) Null statement not in line by itself.
(Rule 57/14.5) continue statement should not be used.
(Rules 59/14.8 & 14.9) Left brace expected for if, else, for, do, and while.
(Rule 65/13.4) Floating point variable used as loop counter.
(Rule 68/8.6) Function not declared at file scope.
(Rule 69/16.1) Function has variable number of arguments.
(Rule 73/16.3) Either all parameters or no parameters should have identifiers.
(Rule 91/19.5) '#define/#undef' used within a block.
(Rule 98/19.12) Multiple use of '#' and/or '##' operators in macro definition.
(Rule 100/19.14) Non-standard use of 'defined' preprocessor operator.
Required checks made exclusively for MISRA 1998 are:
(Rule 58) break used outside of a switch.
(Rule 88) Header file name contains non-standard character.
(Rule 110) Bitfields inside union.
Required checks made exclusively for MISRA 2004 are:
(Rule 8.5) No definitions of objects or function in header files.
(Rules 10.1 & 10.2) Prohibited implicit conversion.
(Rules 10.3 & 10.4) Prohibited cast of complex expressions.
(Rule 10.5) Recasting required for operators '~' and '<<'.
(Rule 12.3) 'sizeof' used on expressions with side effect
(Rule 12.7) Bitwise operator applied to signed underlying type.
(Rule 12.9) Prohibited operator applied to unsigned underlying type.
(Rule 14.6) More than one 'break' terminates loop.
(Rule 14.10) No 'else' at end of 'if ... else if' chain.
(Rule 15.4) Boolean value in switch expression
(Rule 18.4) Unions shall not be used.
(Rule 19.6) Use of '#undef' prohibited
MISRA 1998 checking is achieved using the -misra(1) option. For MISRA 2004 checks, use -misra(2).
You may disable individual rules to your taste by using the Rule number in an esym option. For example:
-esym( 960, 75, 8? )
will suppress MISRA rules 75 and any of the those between 80 and 89 inclusive that are issued as the result of a 960. See [10] for information on the MISRA guidelines.</description>
</rule>
<rule>
<key>961</key>
<configkey>961</configkey>
<priority>INFO</priority>
<name>Violates MISRA Year Advisory Rule Name, String"</name>
<description>This message is issued for some violations of the MISRA advisory guidelines. Certain rules were advisories in the 1998 Standard and became required for the 2004 Standard and vice versa. Therefore, you might see some rules repeated here already listed above for message 960.
The list of advisory checks made for both MISRA 1998 and 2004 are:
(Rule 47/12.1) Dependence placed on C's operator precedence (Rule 87/19.1) Only preprocessor statements and comments before '#include'. (Rule 93/19.7) Use of function-like macros is discouraged. (Rule 102/17.5) More than two pointer indirection levels used.
Advisory checks made exclusively for MISRA 1998 are:
(Rule 18) Constant requires numerical suffix (Rule 28) 'register' class discouraged (Rule 40) 'sizeof' used on expressions with side effect (Rule 44) Redundant explicit casting (Rule 55) Non-case label (Rule 60) No 'else' at end of 'if ... else if' chain. (Rule 63) Boolean value in switch expression (Rule 92) Use of '#undef' is discouraged
Advisory checks made exclusively for MISRA 2004 are:
(Rule 19.2) Header file name contains non-standard character. (Rule 19.13) No use of '#' or '##'.
Messages can be suppressed based on rule number. See also Message 960.</description>
</rule>
<rule>
<key>962</key>
<configkey>962</configkey>
<priority>INFO</priority>
<name>Macro 'Symbol' defined identically at another location (Location)</name>
<description>The same macro was defined in the same way in two different places in the source code. This is not a good practice since a subsequent change to one of the macros could lead to confusion.</description>
</rule>
<rule>
<key>963</key>
<configkey>963</configkey>
<priority>INFO</priority>
<name>Qualifier const or volatile follows/precedes a type; use -fqb/+fqb to reverse the test</name>
<description>The declarations in the following example are equivalent: //lint +e963 report on qualifier-type inversion extern const char *p; extern char const *p; // Note 963 The qualifier 'const' and 'volatile' may appear either before or after or even between other declaration specifiers. Many programmers prefer a consistent scheme such as always placing the qualifier before the type. If you enable 963 (using +e963) this is what you will get by default. The message will contain the word 'follows' rather than the word 'precedes'.
There is a diametrically opposite convention, viz. that of placing the qualifier after the type. As the message itself reminds the user you will obtain the reverse test if you turn off the fqb (place qualifiers before types) flag. Thus //lint -fqb turn off the Qualifiers Before types flag //lint +e963 report on type-qualifier inversion extern const char *p; // Note 963 extern char const *p; Note that the use of this flag will cause 'follows' in the message to be replaced by 'precedes' and the alternative option mentioned within the 'use' clause is changed to its opposite orientation.
Dan Saks [36] and Vandevoorde and Josuttis [32, section 1.4] (14. Added Bibliography), provide convincing evidence that this alternative convention is indeed the better one.</description>
</rule>
<rule>
<key>964</key>
<configkey>964</configkey>
<priority>INFO</priority>
<name>Header file FileName not directly used in module String</name>
<description>The given header file was not used in the given module, however it, itself, included a header file (possibly indirectly) that was used. An example of this is os2.h that is an umbrella header serving only to include other headers. Compare this message with 766.</description>
</rule>
<rule>
<key>966</key>
<configkey>966</configkey>
<priority>INFO</priority>
<name>Indirectly included header file 'FileName' not used by module 'String'</name>
<description>The header file given by FileName was unused directly or indirectly in a given module outside of its group. It was not, however, directly included by the module and so may not easily be excluded without disturbing the header including it. Since this header may be included in other places caution is advised. This message is a weaker version of 766.</description>
</rule>
<rule>
<key>967</key>
<configkey>967</configkey>
<priority>INFO</priority>
<name>Header file 'FileName' does not have a standard include guard</name>
<description>You may protect against the repeated inclusion of headers by means of a standard include guard having the following form: #ifndef Name #define Name ... #endif The header file cited in the message does not have such a guard. It is standard practice in many organizations to always place include guards within every header.
See Warning 451 in Section 13.3 for more information about header include guards.</description>
</rule>
<rule>
<key>970</key>
<configkey>970</configkey>
<priority>INFO</priority>
<name>Use of modifier or type 'Name' outside of a typedef</name>
<description>Some standards require the use of type names (defined in typedef's) in preference to raw names used within the text of the program. For example they may want you to use INT32 rather than int where INT32 is typedef's as:
typedef int INT32;
This message is normally issued for the standard intrinsic types: bool, char, wchar_t, int, float, double, and for modifiers unsigned, signed, short and long. You may enable this message and then suppress the message for individual types to obtain special effects. For example the following will enable the message for all but bool.
+e970 -esym(970,bool)</description>
</rule>
<rule>
<key>971</key>
<configkey>971</configkey>
<priority>INFO</priority>
<name>Use of 'char' without 'signed' or 'unsigned'</name>
<description>The 'char' type was specified without an explicit modifier to indicate whether the char was signed or unsigned. The plain char type can be regarded by the compiler as identifying a signed or an unsigned quantity whichever is more efficient to implement. Because of this ambiguity, some standards do not like the use of char without an explicit modifier to indicate its signedness.</description>
</rule>
<rule>
<key>973</key>
<configkey>973</configkey>
<priority>INFO</priority>
<name>Unary operator in macro 'Symbol' not parenthesized</name>
<description>A unary operator appearing in an expression-like macro was found to be not parenthesized. For example:
#define N -1
The user may prefer to parenthesize such things as:
#define N (-1)
This has been placed in the elective note category because we cannot find an instance when this really produces a problem. The important case of unparenthesized binary operators is covered with message 773.</description>
</rule>
<rule>
<key>974</key>
<configkey>974</configkey>
<priority>INFO</priority>
<name>Worst case function for stack usage: String</name>
<description>This message, issued at global wrap-up, will report on the function that requires the most stack. The stack required consists of the amount of auto storage the function requires plus the amounts required in any chain of functions called. The worst case chain is always reported.
To obtain a report of all the functions, use the +stack option.
Reasonable allowances are made for function call overhead and the stack requirements of external functions. These assumptions can be controlled via the +stack option.
If recursion is detected it will be reported here, as this is considered worse than any finite case. The next worse case is that the stack can't be determined because a function makes a call through a function pointer. The function is said to be non-deterministic. If neither of these conditions prevail, the function that heads the worst case chain of calls will be reported upon.
The message will normally provide you with the name of a called function. If the function is recursive this will provide you with the first call of a recursive loop. To determine the full loop, you will need a full stack report as obtained with the +stack option. You need a suboption of the form &file=file to specify a file which will contain a record for each function for which a definition was found. You will be able to follow the chain of calls to determine the recursive path.
If you can assure yourself through code analysis that there is an upper bound to the amount of stack utilized by some recursive function, then you can employ the +stack option to specify the bound for this function. The function will no longer be considered recursive but rather finite. In this way, possibly through a sequence of options, you can progressively eliminate apparent recursion and in that way arrive at a safe upper bound for stack usage. Similar considerations apply for non-deterministic functions.</description>
</rule>
<rule>
<key>975</key>
<configkey>975</configkey>
<priority>INFO</priority>
<name>Unrecognized pragma 'Name' will be ignored</name>
<description>The first identifier after #pragma is considered the name of the pragma. If the name is unrecognized then the remainder of the line is ignored. Since the purpose of #pragma is to allow for compiler-dependent communication it is not really expected that all pragmas will be understood by all third-party processors of the code. Thus, this message does not necessarily indicate that there is anything wrong and could easily be supressed entirely.
Moreover, if the pragma occurs in a libary header this message would not normally be issued because the option -wlib(1) would be in effect (this option is present in all of our compiler option files).
But if the pragma occurs in user code then it should be examined to see if there is something there that might interest a lint processor. There are a variety of facilities to deal with pragmas; in particular, they can be mapped into languistic constructs or lint options or both. See 3.5 pragmas push_macro and pop_macro and 3.6 Casting pragmas as macros.</description>
</rule>
<rule>
<key>1001</key>
<configkey>1001</configkey>
<priority>CRITICAL</priority>
<name>Scope 'Name' must be a struct or class name</name>
<description>In an expression of the form X::Y, X must be a class name. [11, ?10.4]</description>
</rule>
<rule>
<key>1002</key>
<configkey>1002</configkey>
<priority>CRITICAL</priority>
<name>'this' must be used in class member function</name>
<description>The keyword this refers to the class being passed implicitly to a member function. It is invalid outside a class member function. [11, ?5.1]</description>
</rule>
<rule>
<key>1003</key>
<configkey>1003</configkey>
<priority>CRITICAL</priority>
<name>'this' may not be used in a static member function</name>
<description>A static member function receives no this pointer. [11, ?9.4]</description>
</rule>
<rule>
<key>1004</key>
<configkey>1004</configkey>
<priority>CRITICAL</priority>
<name>Expected a pointer to member after .* or ->*</name>
<description>The .* and ->* operators require pointer to members on the right hand side. [11, ?5.5]</description>
</rule>
<rule>
<key>1005</key>
<configkey>1005</configkey>
<priority>CRITICAL</priority>
<name>Destructor declaration requires class</name>
<description>While expecting a declaration a '~' character was encountered. This was presumed to be the start of a destructor. However no class was specified. [11, ?12.4]</description>
</rule>
<rule>
<key>1006</key>
<configkey>1006</configkey>
<priority>CRITICAL</priority>
<name>Language feature 'String' not supported</name>
<description>The indicated feature, while not supported in the current version, will hopefully be supported in future versions of the product.</description>
</rule>
<rule>
<key>1007</key>
<configkey>1007</configkey>
<priority>CRITICAL</priority>
<name>Pure specifier for function 'Symbol' requires a virtual function</name>
<description>An '=' was found after a declaration. Was this the start of a pure specifier? The declaration was not that of a member function which it must be. Also, the member function should be virtual. [11, ?10.3]</description>
</rule>
<rule>
<key>1008</key>
<configkey>1008</configkey>
<priority>CRITICAL</priority>
<name>Expected '0' to follow '=', text ignored</name>
<description>Some nonstandard extensions to C++ allow integers to follow '=' for declarations of member functions. If you are using such extensions simply suppress this message. If only library headers are using this extension use -elib(1008). [11, ?10.3]</description>
</rule>
<rule>
<key>1009</key>
<configkey>1009</configkey>
<priority>CRITICAL</priority>
<name>operator String not redefinable</name>
<description>The cited operator, one of '.*', '?', '::' or '.', may not be overloaded. [11, ?13.4]</description>
</rule>
<rule>
<key>1010</key>
<configkey>1010</configkey>
<priority>CRITICAL</priority>
<name>Expected a type or an operator</name>
<description>Following the keyword operator the parser expected either an operator (including new, delete, (), [], comma) or a type. [11, ?13.4 and ?12.3.2]</description>
</rule>
<rule>
<key>1011</key>
<configkey>1011</configkey>
<priority>CRITICAL</priority>
<name>Conversion Type Name too long</name>
<description>An upper limit of 50 characters has been reached on a conversion type name.</description>
</rule>
<rule>
<key>1012</key>
<configkey>1012</configkey>
<priority>CRITICAL</priority>
<name>Type not needed before 'operator type'</name>
<description>The return type of a function introduced with 'operator Type' is Type and may not be preceded with the same or any other Type. [11, ?12.3.2]</description>
</rule>
<rule>
<key>1013</key>
<configkey>1013</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Name' not a member of class 'Name'</name>
<description>The second operand of a scope operator or a '.' or '->' operator is not a member of the class (struct or union) expressed or implied by the left hand operand. [11, ?3.2]</description>
</rule>
<rule>
<key>1014</key>
<configkey>1014</configkey>
<priority>CRITICAL</priority>
<name>Explicit storage class not needed for member function 'Symbol'</name>
<description>An explicit Symbol storage class such as extern or static was given in a separate definition of a class member. The storage class is effectively defined by its appearance within the class and may not be restated at definition time.</description>
</rule>
<rule>
<key>1015</key>
<configkey>1015</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Name' not found in class</name>
<description>In an expression of the form X::Y, Y must be a member of X or of a public or protected base class of X. [11, ?10.4]</description>
</rule>
<rule>
<key>1016</key>
<configkey>1016</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Symbol' is supposed to denote a class</name>
<description>In a base-specifier an identifier is supposed to specify a base class. However, the identifier was not previously declared in this module. [11, ?10]</description>
</rule>
<rule>
<key>1017</key>
<configkey>1017</configkey>
<priority>CRITICAL</priority>
<name>conflicting access-specifier 'String'</name>
<description>Two different access specifiers were given in a simple base-specifier. [11, ?10]</description>
</rule>
<rule>
<key>1018</key>
<configkey>1018</configkey>
<priority>CRITICAL</priority>
<name>Expected a type after 'new'</name>
<description>In an expression involving new, a type is expected after possibly processing a placement. None was found. [11, ?5.3.3]</description>
</rule>
<rule>
<key>1019</key>
<configkey>1019</configkey>
<priority>CRITICAL</priority>
<name>Could not find match for function 'Symbol(String)'</name>
<description>In attempting to find a match between a set of overloaded functions or operators (name given as Symbol) and an actual argument list (provided as String) no match could be found. [11, ?13.2]</description>
</rule>
<rule>
<key>1020</key>
<configkey>1020</configkey>
<priority>CRITICAL</priority>
<name>template specialization for 'Symbol' declared without a 'template<>' prefix</name>
<description>A class template specialization is generally preceded by a 'template<>' clause as in: template< class T > class A { }; // a template template<> class A<int> { }; // a specialization If the 'template<>' is omitted, you will get this message but it will still be interpreted as a specialization. Before the standardization of template syntax was completed, a template specialization did not require this clause and its absence is still permitted by some compilers.</description>
</rule>
<rule>
<key>1022</key>
<configkey>1022</configkey>
<priority>CRITICAL</priority>
<name>Function: 'String' must be a class member</name>
<description>There are four operators which may not be defined except as class members. These are:
= () [] ->
The parameter String indicates which it is. [11, ?13.4.3 and ?13.4.6]</description>
</rule>
<rule>
<key>1023</key>
<configkey>1023</configkey>
<priority>CRITICAL</priority>
<name>Call String(String) is ambiguous; candidates: String</name>
<description>A call to an overloaded function or operator is ambiguous. The candidates of choice are provided in the message. [11, ?13.2]</description>
</rule>
<rule>
<key>1024</key>
<configkey>1024</configkey>
<priority>CRITICAL</priority>
<name>No function has same argument count as 'Name'</name>
<description>A call to an overloaded function could not be resolved successfully because no function is declared with the same number of arguments as in the call. [11, ?13.2]</description>
</rule>
<rule>
<key>1025</key>
<configkey>1025</configkey>
<priority>CRITICAL</priority>
<name>No function matches invocation 'Name' on arg no. Integer</name>
<description>A call to an overloaded function could not be resolved because each declared function has a type incompatibility with the indicated argument. [11, ?13.2]</description>
</rule>
<rule>
<key>1026</key>
<configkey>1026</configkey>
<priority>CRITICAL</priority>
<name>Undominated function 'String' does not dominate 'String' on call to 'String'</name>
<description>A call to an overloaded function could not be resolved because no one function dominates all others. This is a subtle issue in the overload resolution process. The selected function must be strictly better than any non-selected function in at least one argument. [11, ?13.2]</description>
</rule>
<rule>
<key>1027</key>
<configkey>1027</configkey>
<priority>CRITICAL</priority>
<name>Non-consecutive default arguments in function 'String', assumed 0</name>
<description>Default arguments need to be consecutive. For example
void f(int i=0, int j, int k=0);
is illegal. [11, ?8.2.6]</description>
</rule>
<rule>
<key>1028</key>
<configkey>1028</configkey>
<priority>CRITICAL</priority>
<name>Last argument not default in first instance of function 'String', assumed 0</name>
<description>If any argument of a function is given a default value then all subsequent arguments need to be given a default value. [11, ?8.2.6]</description>
</rule>
<rule>
<key>1029</key>
<configkey>1029</configkey>
<priority>CRITICAL</priority>
<name>Default argument repeated in function 'String'</name>
<description>A default value for a given argument for a given function should only be given once. [11, ?8.2.6]</description>
</rule>
<rule>
<key>1030</key>
<configkey>1030</configkey>
<priority>CRITICAL</priority>
<name>Not all arguments after arg no. Integer are default in function 'String'</name>
<description>An argument that has a default value must either be followed by another argument that has a default value, or must be the last argument. [11, ?8.2.6]</description>
</rule>
<rule>
<key>1031</key>
<configkey>1031</configkey>
<priority>CRITICAL</priority>
<name>Local variable 'Symbol' used in default argument expression</name>
<description>Default values for arguments may not use local variables. [11, ?8.2.6]</description>
</rule>
<rule>
<key>1032</key>
<configkey>1032</configkey>
<priority>CRITICAL</priority>
<name>Member 'String' cannot be called without object</name>
<description>There was an attempt to call a non-static member function without specifying or implying an object that could serve as the basis for the this pointer. If the member name is known at compile time it will be printed with the message. [11, ?5.24]</description>
</rule>
<rule>
<key>1033</key>
<configkey>1033</configkey>
<priority>CRITICAL</priority>
<name>Static member functions cannot be virtual</name>
<description>You may not declare a static member function virtual. [11, ?10.2]</description>
</rule>
<rule>
<key>1034</key>
<configkey>1034</configkey>
<priority>CRITICAL</priority>
<name>Static member 'Symbol' is global and cannot be redefined</name>
<description>This can come as a surprise to the novice C++ programmer. The word 'static' within a class definition is used to describe a member that is alone and apart from any one object of a class. But such a member has program scope not file scope. The word 'static' outside a class definition implies file scope not program scope. [11, ?9.4]</description>
</rule>
<rule>
<key>1035</key>
<configkey>1035</configkey>
<priority>CRITICAL</priority>
<name>Non-static member 'Symbol' cannot initialize a default argument</name>
<description>A default argument cannot be initialized from a class member unless an instantiation of the class is provided. [11, ?8.2.6]</description>
</rule>
<rule>
<key>1036</key>
<configkey>1036</configkey>
<priority>CRITICAL</priority>
<name>ambiguous reference to constructor; candidates: 'String'</name>
<description>There is more than one constructor that can be used to make a desired conversion. [11, ?12.3.2]</description>
</rule>
<rule>
<key>1037</key>
<configkey>1037</configkey>
<priority>CRITICAL</priority>
<name>ambiguous reference to conversion function; candidates: 'String'</name>
<description>There is more than one conversion function (of the form operator type () ) that will perform a desired conversion. [11, ?12.3.2]</description>
</rule>
<rule>
<key>1038</key>
<configkey>1038</configkey>
<priority>CRITICAL</priority>
<name>type 'Name' not found, nested type 'Name::String' assumed</name>
<description>We have found what appears to be a reference to a type but no such type is in scope. We have, however, been able to locate a type buried within another class. Is this what the user intended? If this is what is intended, use full scoping. If your compiler doesn't support the scoping, suppress with -esym. [11, ?3.2]</description>
</rule>
<rule>
<key>1039</key>
<configkey>1039</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Symbol' is not a member of class 'String'</name>
<description>In a declaration for the symbol X::Y, Y was not previously established as a member of X. [11, ?10.4]</description>
</rule>
<rule>
<key>1040</key>
<configkey>1040</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Symbol' is not a legal declaration within class 'String'</name>
<description>A declaration of the symbol X::Y appears within a class definition (other than for class X). It is not a friend declaration. Therefore it is in error.</description>
</rule>
<rule>
<key>1041</key>
<configkey>1041</configkey>
<priority>CRITICAL</priority>
<name>Can't declare 'String', assumed 'operator String'</name>
<description>This message can be given with String equal to new or delete. A common mistake with beginning C++ programmers is to declare (and/or define) new when they mean to define operator new. We presume this was what was intended. [11, ?12.5]</description>
</rule>
<rule>
<key>1042</key>
<configkey>1042</configkey>
<priority>CRITICAL</priority>
<name>At least one class-like operand is required with Name</name>
<description>In defining (or declaring) an operator you must have at least one class as an operand. [11, ?13.4]</description>
</rule>
<rule>
<key>1043</key>
<configkey>1043</configkey>
<priority>CRITICAL</priority>
<name>Attempting to 'delete' a non-pointer</name>
<description>An expression being delete'd is a non-pointer, non-array. You may only delete that which was created with an invocation of new. [11, ?5.3.4]</description>
</rule>
<rule>
<key>1046</key>
<configkey>1046</configkey>
<priority>CRITICAL</priority>
<name>member 'Symbol', referenced in a static function, requires an object</name>
<description>The Symbol is a non-static member of a class and hence requires a class instantiation. None is in sight. [10, ?9.4]</description>
</rule>
<rule>
<key>1047</key>
<configkey>1047</configkey>
<priority>CRITICAL</priority>
<name>a template declaration must be made at file scope</name>
<description>A template declaration may not appear within a function or within a class. [10, ?14.1]</description>
</rule>
<rule>
<key>1048</key>
<configkey>1048</configkey>
<priority>CRITICAL</priority>
<name>expected a constant expression</name>
<description>Within a template argument list a constant expression was expected. An expression of the form T<arg1,arg2,...> was encountered and arg i for some i corresponds to a non-class parameter in the original template declaration. Such arguments need to be constants. [10, ?14.5]</description>
</rule>
<rule>
<key>1049</key>
<configkey>1049</configkey>
<priority>CRITICAL</priority>
<name>Too many template arguments</name>
<description>There are more arguments in the template class-name than there were parameters in the original template declaration. [10, ?14.5]</description>
</rule>
<rule>
<key>1050</key>
<configkey>1050</configkey>
<priority>CRITICAL</priority>
<name>expected a template argument list '<...>' for template 'Symbol'</name>
<description>The name of a class template identified by Symbol was used without specifying a template argument list. [10, ?14.5]</description>
</rule>
<rule>
<key>1051</key>
<configkey>1051</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Name' is both a function and a variable</name>
<description>Whereas it is possible to overload a function name by giving it two different parameter lists, it is not possible to overload a name in any other way. In particular a function name may not also be used as a variable name. [11, ?9.2]</description>
</rule>
<rule>
<key>1052</key>
<configkey>1052</configkey>
<priority>CRITICAL</priority>
<name>a type was expected, 'class' assumed</name>
<description>A template parameter list consists of 2 kinds of parameters: class identifier and type. The parameter did not begin with class and was not a type. [10, ?14.5]</description>
</rule>
<rule>
<key>1053</key>
<configkey>1053</configkey>
<priority>CRITICAL</priority>
<name>'String' cannot be distinguished from 'String'</name>
<description>An overloaded function name had two parameter lists that were so close that discrimination between them would be difficult and error prone. Eg. void f(const int); and void f(int); [11, ?13]</description>
</rule>
<rule>
<key>1054</key>
<configkey>1054</configkey>
<priority>CRITICAL</priority>
<name>template variable declaration expects a type, int assumed</name>
<description>An expression of the form T<arg,arg,...> was encountered. One of the arguments corresponding to a type parameter in the original template declaration is not a type. [10, ?14.5]</description>
</rule>
<rule>
<key>1055</key>
<configkey>1055</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Symbol' undeclared, assumed to return int</name>
<description>Whereas in C you may call a function without a prior declaration, in C++ you must supply such a declaration. For C programs you would have received an Informational message (718) in this event. [11, ?5.2.2]</description>
</rule>
<rule>
<key>1056</key>
<configkey>1056</configkey>
<priority>CRITICAL</priority>
<name>assignment from void * is not allowed in C++</name>
<description>Whereas in C you may assign from void* to any other (data) pointer without a diagnostic, in C++ you may not do this. It will require a cast. [11, ?4.6]</description>
</rule>
<rule>
<key>1057</key>
<configkey>1057</configkey>
<priority>CRITICAL</priority>
<name>member 'Symbol' cannot be used without an object</name>
<description>The indicated member referenced via scope operator cannot be used in the absence of this pointer. [11, ?5.2.4]</description>
</rule>
<rule>
<key>1058</key>
<configkey>1058</configkey>
<priority>CRITICAL</priority>
<name>Initializing a non-const reference 'Symbol' with a non-lvalue</name>
<description>A reference is normally initialized with an lvalue. If you attempt to initialize a reference with a non-lvalue, a temporary is created to serve as a surrogate lvalue. However, modifications made to the temporary will be lost. This was legal at one time and is now illegal. Make the reference a const if you can. You may be initializing a reference without realizing it. A member function has an implicit parameter which is taken to be a reference to its object. If this is the situation make the member const. That is, use void f(...) const; rather than void f(...);</description>
</rule>
<rule>
<key>1059</key>
<configkey>1059</configkey>
<priority>CRITICAL</priority>
<name>Can't convert from 'Type' to 'Type'</name>
<description>An attempt was made to initialize a reference with an object having a type other than the target type but no function could be found to effect the required conversion. [11, ?12.3]</description>
</rule>
<rule>
<key>1060</key>
<configkey>1060</configkey>
<priority>CRITICAL</priority>
<name>String member 'Symbol' is not accessible to non-member non-friend functions</name>
<description>There is an attempt to access a private or protected member of a class and the access is considered a violation of the access rules (although everything else proceeds as though no violation occurred). Specifically, the function attempting to make access must be a friend or member of the nominal class through which the access is made. See also 1061. [11, ?11]</description>
</rule>
<rule>
<key>1061</key>
<configkey>1061</configkey>
<priority>CRITICAL</priority>
<name>String member 'Symbol' is not accessible through non-public inheritance</name>
<description>There is an attempt to access a private, protected or public member (the text of the message indicates which kind as well as which member) of a class through a class derived from the original. There is an access violation (see 1060 for the more common access violation) critically dependent on the fact that the inheritance relationship is non-public. [11, ?11.2]</description>
</rule>
<rule>
<key>1062</key>
<configkey>1062</configkey>
<priority>CRITICAL</priority>
<name>template must be either a class or a function</name>
<description>Following template < arglist > the parser expects to find either the token class or a function declaration or definition. [10, ?14.5]</description>
</rule>
<rule>
<key>1063</key>
<configkey>1063</configkey>
<priority>CRITICAL</priority>
<name>Argument to copy constructor for class 'Symbol' should be a reference</name>
<description>A constructor for a class closely resembles a copy constructor. A copy constructor for class X is typically declared as:
X( const X &)
If you leave off the '&' then a copy constructor would be needed just to copy the argument into the copy constructor. This is a runaway recursion. [11, ?12.1]</description>
</rule>
<rule>
<key>1064</key>
<configkey>1064</configkey>
<priority>CRITICAL</priority>
<name>Template parameter list for template 'Symbol' inconsistent with Location</name>
<description>The template parameter list for a template function declaration or definition is inconsistent with that of a prior declaration or definition. [10, ?14.5]</description>
</rule>
<rule>
<key>1065</key>
<configkey>1065</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Symbol' not declared as "C" conflicts with Location</name>
<description>A symbol previously declared as extern "C" in some other module is not declared as extern "C" in this module. This could be the source of very mysterious linker diagnostics since a name declared as extern "C" is not subject to the name mangling procedures that strictly C++ functions are. [11, ?7.4]</description>
</rule>
<rule>
<key>1066</key>
<configkey>1066</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Symbol' declared as "C" conflicts with Location</name>
<description>A symbol is being declared as extern "C" and was not so declared in some other module. This could be the source of very mysterious linker diagnostics since a name declared as extern "C" is not subject to the name mangling procedures that strictly C++ functions are. [11, ?7.4]</description>
</rule>
<rule>
<key>1067</key>
<configkey>1067</configkey>
<priority>CRITICAL</priority>
<name>invalid prototype for function 'Symbol'</name>
<description>Whenever operator delete or operator delete [] is defined its first parameter must be declared as void *. For member functions an optional second parameter may be size_t. [10, ?12.5].</description>
</rule>
<rule>
<key>1068</key>
<configkey>1068</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Symbol' can not be overloaded</name>
<description>operator delete or operator delete [] can be redefined but not overloaded. There can only be one operator delete and one operator delete [] but neither of these can be overloaded. [10, ?12.5].</description>
</rule>
<rule>
<key>1069</key>
<configkey>1069</configkey>
<priority>CRITICAL</priority>
<name>Symbol 'Name' is not a base class of class 'Name'</name>
<description>Within a constructor initialization list a name was found that did not correspond to either a direct base class of the class being defined or a member of the class.</description>
</rule>
<rule>
<key>1070</key>
<configkey>1070</configkey>
<priority>CRITICAL</priority>
<name>No scope in which to find symbol 'Name'</name>
<description>This could arise in an expression of the form X::Y where X does not represent a valid scope.</description>
</rule>
<rule>
<key>1071</key>
<configkey>1071</configkey>
<priority>CRITICAL</priority>
<name>Constructors and destructors can not have return type</name>
<description>Constructors and destructors may not be declared with a return type, not even void. See ARM Section 12.1 and 12.4.</description>
</rule>
<rule>
<key>1072</key>
<configkey>1072</configkey>
<priority>CRITICAL</priority>
<name>Reference variable 'Symbol' must be initialized</name>
<description>A reference variable must have an initializer at the point of declaration.</description>
</rule>
<rule>
<key>1073</key>
<configkey>1073</configkey>
<priority>CRITICAL</priority>
<name>Insufficient number of template parameters for 'Symbol'; 'String' assumed</name>
<description>A (class) template instantiation did not have a sufficient number of parameters. String indicates what the missing argument is presumed to be.</description>
</rule>
<rule>
<key>1074</key>
<configkey>1074</configkey>
<priority>CRITICAL</priority>
<name>Expected a namespace identifier</name>
<description>In a declaration of the form: namespace name = scoped-identifier
the scoped-identifier must identify a namespace.</description>
</rule>
<rule>
<key>1075</key>
<configkey>1075</configkey>
<priority>CRITICAL</priority>
<name>Ambiguous reference to symbol 'Symbol' and symbol 'Symbol'</name>
<description>Two namespaces contain the same name. A reference to such a name could not be disambiguated. You must fully qualify this name in order in indicate which name is intended.</description>
</rule>
<rule>
<key>1076</key>
<configkey>1076</configkey>
<priority>CRITICAL</priority>
<name>Anonymous union assumed to be 'static'</name>
<description>Anonymous unions need to be declared static. This is because the names contained within are considered local to the module in which they are declared.</description>
</rule>
<rule>
<key>1077</key>
<configkey>1077</configkey>
<priority>CRITICAL</priority>
<name>Could not evaluate default template parameter 'String'</name>
<description>The evaluation of template parameters is deferred until needed. Thus:
template< class T = abc > class A { /* ... */ };
will be greeted with an Error 1077 only if an instantiation of A<> requires evaluation of the default argument and if that evaluation cannot be made. In that event int is assumed for type parameters and 0 is assumed for object parameters.</description>
</rule>
<rule>
<key>1078</key>
<configkey>1078</configkey>
<priority>CRITICAL</priority>
<name>class 'Symbol' should not have itself as a base class</name>
<description>The following situation will trigger this message.
class A : public A { };
You can't define A in terms of itself as there is no escape from the recursive plummet.</description>
</rule>
<rule>
<key>1079</key>
<configkey>1079</configkey>
<priority>CRITICAL</priority>
<name>Could not find '>' or ',' to terminate template parameter at Location</name>
<description>The default value for a template parameter appears to be malformed. For example, suppose the user mistakenly substituted a ']' for a '>' producing the following: template <class T = A< int ] > class X { };
This will cause PC-lint/FlexeLint to process to the end of the file looking (in vain) for the terminating pointy bracket. Not finding it will cause this message to be printed. Fortunately, the message will bear the Location of the malformed template.</description>
</rule>
<rule>
<key>1080</key>
<configkey>1080</configkey>
<priority>CRITICAL</priority>
<name>Definition for class 'Name' is not in scope</name>
<description>This message would be issued whenever a class definition were required and it were not available. For example:
class X; // declare class X X *p; // OK, no definition required X a; // Error 1080</description>
</rule>
<rule>
<key>1081</key>
<configkey>1081</configkey>
<priority>CRITICAL</priority>
<name>Object parameter does not contain the address of a variable</name>
<description>A template argument that is passed to a pointer parameter is supposed to identify a symbol. The expression passed does not do so. For example template< int *P > class A { ... }; int a[10]; A< a+2 > x; // a+2 does not represent a symbol</description>
</rule>
<rule>
<key>1082</key>
<configkey>1082</configkey>
<priority>CRITICAL</priority>
<name>Object parameter for a reference type should be an external symbol</name>
<description>A template argument that is passed to a reference parameter is supposed to identify an external symbol. The expression passed does not do so. For example template< int &I > class A { ... }; int a[10]; A< a[2] > x; // a[2] does not represent a symbol See also message 1081.</description>
</rule>
<rule>
<key>1083</key>
<configkey>1083</configkey>
<priority>CRITICAL</priority>
<name>Ambiguous conversion between 2nd and 3rd operands of conditional operator</name>
<description>If the 2nd operand can be converted to match the type of the 3rd, and the 3rd operand can be converted to match the type of the 2nd, then the conditional expression is considered ill-formed.</description>
</rule>
<rule>
<key>1084</key>
<configkey>1084</configkey>
<priority>CRITICAL</priority>
<name>Ambiguous use of template-id for instantiation of 'Type'</name>
<description>When the language calls for a class template to be instantiated and the primary template is "overloaded" via one or more partial specializations, there is an attempt to see if the template arguments match any of those partial specializations. (Note, explicit specializations would have been considered before determining that the class definition needs to be generated by way of instantiation.) If multiple partial specializations match then:
- If one of the matching partial specializations is more specialized than all others then it is used for the instantiation.
- Otherwise, the program is ill-formed, so Lint issues message 1084.
In the message, the matching partial specializations are provided as the list of candidates. Example: template<class T1, class T2, int I> class A {}; //#1 template<class T1, class T2, int I> class A<T1*, T2, I> {}; //#2 template<class T1, class T2, int I> class A<T1, T2*, I> {}; //#3 A<int*, int*, 2> a; // ambiguous: matches #2 and #3 // (and neither template is more specialized than the other)</description>
</rule>
<rule>
<key>1085</key>
<configkey>1085</configkey>
<priority>CRITICAL</priority>
<name>Invalid definition of 'String'</name>
<description>An attempt was made to define a member of a template before the template was defined. Example: template<class T, class U> struct A { void }; template<class U, class T> void A<T,U>::f(){} // Error 1085 In this case, the template argument list is out of order; T and U have been interchanged.</description>
</rule>
<rule>
<key>1086</key>
<configkey>1086</configkey>
<priority>CRITICAL</priority>
<name>Compound literals may only be used in C99 programs</name>
<description>Compound literals are defined in C99 ([4] ISO/IEC 9899:1999). However, some compilers allow the use of compound literals in C++. If you plan to port your code to another C++ compiler, then it may be worthwhile to heed this message; otherwise it may be safely suppressed with -e1086.</description>
</rule>
<rule>
<key>1087</key>
<configkey>1087</configkey>
<priority>CRITICAL</priority>
<name>Previous declaration of 'Name' (Location) is incompatible with 'Name' (Location) which was introduced by the current using-declaration</name>
<description>A using declaration such as:
using NS::name;
seems to be in error. It introduces a name that clashes with the name introduced earlier by another using-declaration. E.g.: namespace N { int i;} namespace Q { void i();} using N::i; using Q::i; // Error 1087 issued here.</description>
</rule>
<rule>
<key>1088</key>
<configkey>1088</configkey>
<priority>CRITICAL</priority>
<name>A using-declaration must name a qualified-id</name>
<description>This error is issued when a using-declaration references a name without the :: scope resolution operator; e.g.: class A { protected: int n; }; class B : public A { public: using n; // Error 1088: should be 'using A::n;' }; See Section 14. Added Bibliography, [34], 7.3.3 namespace.udecl.</description>
</rule>
<rule>
<key>1089</key>
<configkey>1089</configkey>
<priority>CRITICAL</priority>
<name>A using-declaration must not name a namespace</name>
<description>This error is issued when the rightmost part of the qualified-id in a using-declaration is the name of a namespace. E.g.: namespace N { namespace Q{ void g(); } } void f() { using ::N::Q; // Error 1089 Q::g(); } Instead, use a namespace-alias-definition: namespace N { namespace Q{ void g(); } } void f() { namespace Q = ::N::Q; // OK Q::g(); // OK, calls ::N::Q::g(). } See Section 14. Added Bibliography, [35], Issue 460.</description>
</rule>
<rule>
<key>1090</key>
<configkey>1090</configkey>
<priority>CRITICAL</priority>
<name>A using-declaration must not name a template-id</name>
<description>This error is issued when the rightmost part of the qualified-id in a using-declaration is a template-id. E.g.: template<class T> class A { protected: template<class U> class B{}; };
struct D : public A<int> { public: using A<int>::B<char*>; // Error 1090 };
D::B<char*> bc; Instead, refer to the template name without template arguments: template<class T> class A { protected: template<class U> class B{}; };
struct D : public A<int> { public: using A<int>::B; // OK };
D::B<char*> bc; // OK See Section 14. Added Bibliography, [34], 7.3.3 namespace.udecl.</description>
</rule>
<rule>
<key>1091</key>
<configkey>1091</configkey>
<priority>CRITICAL</priority>
<name>'Name' is not a base class of 'Name'</name>
<description>This error is issued when the nested-name-specifier of the qualified-id in a using-declaration does not name a base class of the class containing the using-declaration; e.g.: struct N { void f(); }
class A { protected: void f(); }; class B : A { public: using N::f; // Error 1091 }; See Section 14. Added Bibliography, [35], Issue 400.</description>
</rule>
<rule>
<key>1092</key>
<configkey>1092</configkey>
<priority>CRITICAL</priority>
<name>A using-declaration that names a class member must be a member-declaration</name>
<description>This error is issued when the nested-name-specifier of the qualified-id in a using-declaration names a class but the using-declaration does not appear where class members are declared. E.g.: struct A { void f(); };
struct B : A{ void g() { using A::f; // Error 1092 } }; See Section 14. Added Bibliography, [34], 7.3.3 namespace.udecl.</description>
</rule>
<rule>
<key>1093</key>
<configkey>1093</configkey>
<priority>CRITICAL</priority>
<name>A pure specifier was given for function 'Symbol' which was not declared virtual</name>
<description>A pure specifier ("= 0") should not be placed on a function unless the function had been declared "virtual".</description>
</rule>
<rule>
<key>1094</key>
<configkey>1094</configkey>
<priority>CRITICAL</priority>
<name>Could not find ')' or ',' to terminate default function argument at Location</name>
<description>A default function argument was found which did not seem to include any terminating tokens (the ',' separating arguments or ')' ending the function's argument list). Consequently, Lint continued scanning to the end of the file. Location indicates where the default argument began.</description>
</rule>
<rule>
<key>1095</key>
<configkey>1095</configkey>
<priority>CRITICAL</priority>
<name>Effective type 'Type' of non-type template parameter #Integer (corresponding to argument expression 'String') depends on an unspecialized parameter of this partial specialization</name>
<description>The ISO C++ Standard says that "the type of a template parameter corresponding to a specialized non-type argument shall not be dependent on a parameter of the specialization." See Section 14. Added Bibliography, [34], 14.5.4 temp.class.spec. Example: // primary template: template<class T, T N, class U> struct B;
// PS #1: template<class U> struct B<int,257,U>; // Ok
// PS #2: template<class U> struct B<bool,257,U>; // Ok, same as: template<class U> struct B<bool,true,U>; // Ok (redeclaration of #2)
// PS #3: template<class U> struct B<T,257,U>; // Error 1095 here In PS #3, the value 257 is the 'specialized non-type argument' and its corresponding parameter is 'N' whose type is T which was not made concrete. But in PS #1 and PS #2, T was given the concrete types 'int' and 'bool', respectively.</description>
</rule>
<rule>
<key>1096</key>
<configkey>1096</configkey>
<priority>CRITICAL</priority>
<name>A target ctor must be the only mem-initializer in the mem-initializer-list of a delegating ctor</name>
<description>C++0x requires that if a constructor delegates to another constructor, then the mem-initializer (the region between the colon and the function body) must contain only one item, and that item must be a call to another constructor (which is called the "target constructor"). Example: struct A { int n; A(int); A( const A& p) : A(p.n) {} // Ok A() : n(42), A(32) // Error 1096 {} };</description>
</rule>
<rule>
<key>1097</key>
<configkey>1097</configkey>
<priority>CRITICAL</priority>
<name>Delegating ctor delegates directly to itself, causing infinite recursion</name>
<description>Example: struct A { int n; A(int x) : A(x){} // Error 1097 };</description>
</rule>
<rule>
<key>1098</key>
<configkey>1098</configkey>
<priority>CRITICAL</priority>
<name>Function template specialization 'Symbol' does not match any function template</name>
<description>This message is issued for a declaration where the user apparently intended to name a specialization of a function template (e.g., in an explicit specialization, an explicit instantiation or a friend declaration of specialization), but no previously-declared function template is matched. Example: template<class T> void f( const T& ); // #1
struct A{}; template<> void f( const A& ); // Ok // (A is the deduced argument to T.)
struct B{}; template<> void f( const B ); // Error 1097. // (A template argument cannot be deduced for T.)</description>
</rule>
<rule>
<key>1099</key>
<configkey>1099</configkey>
<priority>CRITICAL</priority>
<name>Ambiguous function template specialization 'Symbol'</name>
<description>This message is issued for a declaration where the user apparently intended to name a specialization of a function template (e.g., in an explicit specialization, an explicit instantiation or a friend declaration of specialization), but the specialization matches multiple function templates, and none of the matched templates is more specialized than all of the other matching templates. The candidates (i.e., the matching templates) are provided in the message. Example: template<class T> struct A {};
template<class T, class U> void f( T*, U ); // #1 template<class T, class U> void f( T, A<U> ); // #2
struct B{}; template<> void f( B, A<B> ); // Ok // #1 does not match but #2 does.
template<> void f( char*, A<int> ); // Error 1099 // Both #1 and #2 match and neither is more specialized than the // other. This situation can be avoided in at least a couple of ways. One way is to explicitly specify one or more template arguments. Example: // continuing from above... template<> void f<char*>( char*, A<int> ); // Ok // #1 does not match but #2 does. Another way is to use SFINAE tactics in the declaration of one or more function templates, e.g. with boost::enable_if.</description>
</rule>
<rule>
<key>1100</key>
<configkey>1100</configkey>
<priority>CRITICAL</priority>
<name>Declaration of 'Symbol' does not declare an explicit specialization, explicit instantiation or friend</name>
<description>In a declaration that explicitly specifies template arguments with angle brackets immediately after the name of a function template, the declaration must declare either an explicit specialization, explicit instantiation or friend. (Note, an explicit specialization always begins with 'template<>' and an explicit instantiation always begins with 'template'</name><description>-without angle brackets after the keyword 'template'.) template<class T> struct A {};
template<class T> inline void f( A<T> ); // #1 void f( A<int> ); // #2 // Ok, declares an ordinary function
void f<char>( A<char> ); // Error 1100</description>
</rule>
<rule>
<key>1101</key>
<configkey>1101</configkey>
<priority>CRITICAL</priority>
<name>Type of variable 'Symbol' cannot be deduced from its initializer</name>
<description>Example: int f(void); int f(char*); auto n = f; // Error In terms of deduction, this is equivalent to: int f(void); int f(char*); template<class T> void g( const T& ); void h( void ) { g( f ); // Error } Here, 'f' refers to multiple overloaded functions, so it is an ambiguous reference and T cannot be deduced. (Code like this could still be well-formed however, e.g. if g is overloaded with a non-template function whose parameter type is 'ptr-to-function returning int taking (char*)'.)</description>
</rule>
<rule>
<key>1102</key>
<configkey>1102</configkey>
<priority>CRITICAL</priority>
<name>auto type deduced inconsistently: 'Type' for 'Symbol' but 'Type' for 'Symbol'</name>
<description>When multiple variables are defined in the same declaration, and when that declaration uses the keyword auto as the type-specifier (a feature of C++0x), the type for which auto is a placeholder must be the same for each variable. Example: float g(void); char* s(); auto a = 42; // Ok, auto is 'int' auto b = g(); // Ok, auto is 'float' auto c = 'q', *d = s(); // Ok, auto is 'char' (for both c and d) auto x = 42, y = g(); // Error 1102 here</description>
</rule>
<rule>
<key>1103</key>
<configkey>1103</configkey>
<priority>CRITICAL</priority>
<name>Type 'Type' is not allowed as an enum-base</name>
<description>When an enumeration type is declared with an explicit underlying type, that type must be integral. Example: enum A : bool; // ok enum B : short; // ok enum C : unsigned long long; // ok enum D : float; // Error 1103</description>
</rule>
<rule>
<key>1104</key>
<configkey>1104</configkey>
<priority>CRITICAL</priority>
<name>A reference to enumeration 'Symbol' should not use 'String'</name>
<description>Although an enumeration may be declared or defined using a scope indicator or an underlying type indicator, these should not be applied when simply referencing the enumeration. E.g. enum class A { red, green }; enum class A x; // Error -- don't need 'class' enum A : unsigned { red, green }; enum A : unsigned y; // Error -- don't need ': unsigned'</description>
</rule>
<rule>
<key>1105</key>
<configkey>1105</configkey>
<priority>CRITICAL</priority>
<name>Use of ref qualification of 'Symbol' inconsistent with overloaded function 'Symbol' (Location)"</name>
<description>If an explicit ref qualifier ('&' or '&&') of a nonstatic member function is employed, an explicit ref qualifier needs to be used with every member of the overload set. Thus: class A { void f(int) &; // ok (so far) void f(int); // 1105 void f(double); // 1105 void g(int); // ok (fresh function) void g(double); // still ok };</description>
</rule>
<rule>
<key>1106</key>
<configkey>1106</configkey>
<priority>CRITICAL</priority>
<name>Initializing value 'String' of enumerator 'Name' cannot be represented by the enumeration's underlying type 'Type'</name>
<description>An enumerator is being initialized with a value that is inappropriate to the declared type of the initializer. Example: enum E : unsigned char { e = 256 }; The value 256 cannot be represented by an unsigned char.</description>
</rule>
<rule>
<key>1107</key>
<configkey>1107</configkey>
<priority>CRITICAL</priority>
<name>Mixing two different kinds of string literals</name>
<description>Two string literals are being concatenated which have different types. Examples: char *s = u"abc" U"def"; char *q = "L"ghi" u"jkl"; This message is issued for mixing strings of char16_t, char32_t, and/or wchar_t (as shown). Literal string concatenation of any of these with an ordinary character literal is permitted and will receive Informational 707.
error;1108;Use of deleted function 'Symbol' defined at 'Location' This message is issued when a deleted function is used. Example: void f( int ) = delete; void f( double ); void g( double d, int n ) { f( d ); // Ok f( n ); // Error }</description>
</rule>
<rule>
<key>1110</key>
<configkey>1110</configkey>
<priority>CRITICAL</priority>
<name>Cycle detected: explicit application of 'Name'::operator-> causes infinite implicit applications of the same operator</name>
<description>When an overloaded operator-> is used as in a->b it is effectively expanded to: a.operator->()->b And this expansion repeats until an operator-> is found that does not yield a class type. But in the process of evaluating this expansion, it might be found that one of the operators returns a class type for which an overloaded operator-> was already expanded; in that case, Error 1110 is triggered. Example: struct B; struct A { struct B& operator->(); }; struct B { struct A& operator->(); }; int f( A & p ) { p->g(); } // Error</description>
</rule>
<rule>
<key>1111</key>
<configkey>1111</configkey>
<priority>CRITICAL</priority>
<name>ISO C++ requires an explicit specialization/instantiation to appear at namespace scope</name>
<description>This message is issued at the beginning of each explicit specialization/instantiation that does not appear at namespace scope. Example: struct A { template <typename U> struct B {};
// template <> // Would be ill-formed by ISO C++. // struct B<int> {}; }; template<> struct A::B<int> {}; // Ok. There is an additional limitation with member class templates of class templates. As with members of a non-template class, one cannot write a specialization at class scope. Example: template<typename T> struct G { template <typename U> struct H {}; // template <> // Would be ill-formed by ISO C++. // struct H<int> {}; }; But the language specification does not even allow this to be expressed in a namespace-scope definition; there is no way to write an explicit specialization that is a member of a class template. Example: template<typename T> struct J { template <typename U> struct K {}; }; // template<typename T> // template <> // Would be ill-formed by ISO C++; // struct J<T>::K<int> {}; This is because the rules for explicit specializations say that 'template<>' is not allowed to appear after a non-empty template-parameter-list within the same declaration. However, one may write an explicit specialization that is a member of an implicitly-instantiated specialization of a class template. Example: template<typename T> struct L { template <typename U> struct M {}; }; template <> template <> struct L<char>::M<int> {}; // Ok Here, the body of the class L<char> is automatically generated by implicit instantiation (otherwise the reference to 'L<char>::M' would be ill-formed), while the body of L<char>::M<int> is provided in the explicit specialization.
In March of 2009, the ISO C++ committee reviewed a report submitted against this example: struct A { template<class T> struct B; template <class T> struct B<T*> { }; // well-formed template <> struct B<int*> { }; // ill-formed }; While it might seem odd that one is able to write the partial specialization but not the full specialization, the committee (which at the time was in a "feature-freeze" mode and trying to finalize a draft for the next International Standard) decided that this capability would need to be regarded as an "extension", meaning that it could be considered as a new feature in a future standard but not as a bug-fix for C++0x.
Note that the Microsoft compiler implements this extension. For that reason, the Lint option -elib(1111) appears in recent versions of our configuration files for Microsoft compilers.</description>
</rule>
<rule>
<key>1112</key>
<configkey>1112</configkey>
<priority>CRITICAL</priority>
<name>In a declaration, the form 'auto D(parms)->type' is the only valid way to use a trailing-return-type</name>
<description>In a declaration, the form 'auto D(parms)->type' (where D is either a name or a parenthesized region) is the only valid way to use a trailing-return-type</description>
</rule>
<rule>
<key>1268</key>
<configkey>1268</configkey>
<priority>BLOCKER</priority>
<name>Internal Error; contact Gimpel Software</name>
<description>Internal Error -- Some inconsistency or contradiction was discovered in the PC-lint/FlexeLint system. This may or may not
be the result of a user error. This inconsistency should be brought to the attention of Gimpel Software</description>
</rule>
<rule>
<key>1401</key>
<configkey>1401</configkey>
<priority>MAJOR</priority>
<name>member 'Symbol' (Location) not initialized by constructor</name>
<description>The indicated member symbol was not initialized by a constructor. Was this an oversight?</description>
</rule>
<rule>
<key>1402</key>
<configkey>1402</configkey>
<priority>MAJOR</priority>
<name>member 'Symbol' (Location) not initialized</name>
<description>The indicated member symbol was not initialized prior to use. Either this is in a constructor where it is presumed that no members are pre-initialized or this is after a statement which will remove its initialization such as a delete or a free.</description>
</rule>
<rule>
<key>1403</key>
<configkey>1403</configkey>
<priority>MAJOR</priority>
<name>member 'Symbol' (Location) not initialized</name>
<description>The indicated member symbol was not initialized prior to a point where its address is being passed to a constant pointer. This looks suspicious. Either this is in a constructor where it is presumed that no members are pre-initialized or this is after a statement which will remove its initialization such as a delete or a free.</description>
</rule>
<rule>
<key>1404</key>
<configkey>1404</configkey>
<priority>MAJOR</priority>
<name>deleting an object of type 'Symbol' before type is defined</name>
<description>The following situation was detected:
class X; ... X *p; ... delete p;
That is, a placeholder declaration for a class is given and an object of that type is deleted before any definition is seen. This may or may not be followed by the actual class definition:
class X { ... };
A delete before the class is defined is dangerous because, among other things, any operator delete that may be defined within the class could be ignored.</description>
</rule>
<rule>
<key>1405</key>
<configkey>1405</configkey>
<priority>MAJOR</priority>
<name>Header typeinfo must be included before typeid is used</name>
<description>According to Section 5.2.8 (para 6) of the C++ standard [10], "If the header <typeinfo> (18.5.1) is not included prior to a use of typeid, the program is ill-formed." A typeid was found in the program but the required include was not.</description>
</rule>
<rule>
<key>1411</key>
<configkey>1411</configkey>
<priority>MAJOR</priority>
<name>Member with different signature hides virtual member 'Symbol' (Location)</name>
<description>A member function has the same name as a virtual member of a derived class but it has a different signature (different parameter list). This is legal but suspicious, because it looks as though the function would override the virtual function but doesn't. You should either adjust the parameters of the member so that the signatures conform or choose a different name. See also message 1511.</description>
</rule>
<rule>
<key>1412</key>
<configkey>1412</configkey>
<priority>MAJOR</priority>
<name>Reference member 'Symbol' is not initialized</name>
<description>A class member typed reference to class (or struct or union) is mentioned in a constructor initializer list. But the class (or struct or union) referenced has no constructor and so is never initialized.</description>
</rule>
<rule>
<key>1413</key>
<configkey>1413</configkey>
<priority>MAJOR</priority>
<name>function 'Symbol' is returning a temporary via a reference</name>
<description>It appears that a function (identified as Symbol in the message) declared to return a reference is returning a temporary. According to the C++ standard (Section 12.2), in addressing the issue of binding temporary values to references, says "A temporary bound to the returned value in a function return statement ... persists until the function exits". Thus the information being returned is not guaranteed to last longer than the function being called.
It would probably be better to return by value rather than reference. Alternatively, you may return a static variable by reference. This will have validity at least until the next call upon the same function.</description>
</rule>
<rule>
<key>1414</key>
<configkey>1414</configkey>
<priority>MAJOR</priority>
<name>Assigning address of auto variable 'Symbol' to member of this</name>
<description>The address of an auto variable was taken and assigned to a this member in a member function. For example: struct A { char *x; void f() { char y[10]; x = y; // warning 1414 } }; Here the address of y is being passed to member x but this is dangerous (if not ridiculous) since when the function returns, the storage allocated for y is deallocated and the pointer could very easily harm something.</description>
</rule>
<rule>
<key>1415</key>
<configkey>1415</configkey>
<priority>MAJOR</priority>
<name>Pointer to non-POD class 'Name' passed to function 'Symbol' (Context)</name>
<description>A non-POD class is one which goes beyond containing just Plain Old Data (POD). In particular it may have private or protected data or it may have constructors or destructors or copy assignment. All of these things disqualify it from being a POD. A POD is fully defined in the C++ standard (Clause 9).
Some functions such as memcpy, memcmp, memmove, etc. are expected to be given only pointers to POD objects. The reason is that only POD objects have the property that they can be copied to an array of bytes and back again with a guarantee that they will retain their original value. (See Section 3.9 of the C++ standard). See also Semantic pod(i) in Section 4. Semantics</description>
</rule>
<rule>
<key>1416</key>
<configkey>1416</configkey>
<priority>MAJOR</priority>
<name>An uninitialized reference 'Symbol' is being used to initialize reference 'Symbol'</name>
<description>This message is usually issued when a reference to a member of a class is used to initialize a reference to another member of the same class before the first member was initialized. For example: class C { int &n, &m; C( int &k ) : n(m), m(k) { /* ... */ } }; Here m is initialized properly to be identical to k. However, the initialization of n, taking place, as it does, before m is so initialized, is erroneous. It is undefined what location n will reference.</description>
</rule>
<rule>
<key>1417</key>
<configkey>1417</configkey>
<priority>MAJOR</priority>
<name>reference member 'Symbol' not initialized by constructor initializer list</name>
<description>This message is issued when a reference data member of a class does not appear in a mem-initializer. For example, the following code will result in a Warning 1417 for symbol m since a mem-initializer is the only way that m can be reference initialized. class C { int &n, &m; C( int &k ) : n(k) { /* ... */ } };</description>
</rule>
<rule>
<key>1501</key>
<configkey>1501</configkey>
<priority>MAJOR</priority>
<name>data member 'Symbol' has zero size</name>
<description>A data member had zero size. It could be an array of zero length or a class with no data members. This is considered an error in C (Error 43) but in C++ we give this warning. Check your code to make sure this is not an error. Some libraries employ clever templating which will elicit this message. In such a case it is necessary for you to inhibit the message outright (using -e1501) or through a judicious use of -esym(1501,...).</description>
</rule>
<rule>
<key>1502</key>
<configkey>1502</configkey>
<priority>MAJOR</priority>
<name>defined object 'Symbol' has no nonstatic data members</name>
<description>A variable (Symbol) is being instantiated that belongs to a class that contains no data members (either directly or indirectly through inheritance). [11, ?9]</description>
</rule>
<rule>
<key>1503</key>
<configkey>1503</configkey>
<priority>MAJOR</priority>
<name>a tagged union is not anonymous</name>
<description>A tagged union without a declarator appeared within a struct/union declaration. An anonymous union requires no tag. [11, ?9.5]</description>
</rule>
<rule>
<key>1504</key>
<configkey>1504</configkey>
<priority>MAJOR</priority>
<name>useless struct declaration</name>
<description>An untagged struct declaration appeared within a struct/union and has no declarator. It is not treated like an anonymous union. Was this intended?</description>
</rule>
<rule>
<key>1505</key>
<configkey>1505</configkey>
<priority>MAJOR</priority>
<name>no access specifier provided, 'String' assumed</name>
<description>A base class specifier provides no access specifier (public, private or protected). An explicit access specifier is always recommended since the default behavior is often not what is expected. For example:
class A : B { int a; };
would make B a private base class by default.
class A : private B { int a; };
is preferred if that's what you want. [11, ?11.1]</description>
</rule>
<rule>
<key>1506</key>
<configkey>1506</configkey>
<priority>MAJOR</priority>
<name>Call to virtual function 'Symbol' within a constructor or destructor</name>
<description>A call to a virtual function was found in a constructor or a destructor of a class. If this class is a base class of some other class (why else make a virtual call?), then the function called is not the overriding function of the derived class but rather the function associated with the base class. If you use an explicit scope operator this message will not be produced. [20, ?9]</description>
</rule>
<rule>
<key>1507</key>
<configkey>1507</configkey>
<priority>MAJOR</priority>
<name>attempting to 'delete' an array</name>
<description>The type of an object to be delete'd is usually a pointer. This is because operator new always returns a pointer and delete may only delete that which has been allocated via new. Perhaps this is a programmer error attempting to delete an auto array? [19]</description>
</rule>
<rule>
<key>1509</key>
<configkey>1509</configkey>
<priority>MAJOR</priority>
<name>base class destructor for class 'Name' is not virtual</name>
<description>The indicated class is a base class for some derived class. It has a destructor which is not virtual. Was this a mistake? It is conventional to virtualize destructors of base classes so that it is safe to delete a base class pointer. [19]</description>
</rule>
<rule>
<key>1510</key>
<configkey>1510</configkey>
<priority>MAJOR</priority>
<name>base class 'Name' has no destructor</name>
<description>The indicated class is a base class for some derived class that has a destructor. The base class does not have a destructor. Is this a mistake? The difficulty that you may encounter is this; if you represent (and manipulate) a heterogeneous collection of possibly derived objects via a pointer to the base class then you will need a virtual base class destructor to invoke the derived class destructor. [13, ?4]</description>
</rule>
<rule>
<key>1511</key>
<configkey>1511</configkey>
<priority>MAJOR</priority>
<name>Member hides non-virtual member 'Symbol' (Location)</name>
<description>The named member of a derived class hides a similarly named member of a base class. Moreover, the base class member is not virtual. Is this a mistake? Was the base member supposed to have been declared virtual? By unnecessarily using the same name, confusion could be created.</description>
</rule>
<rule>
<key>1512</key>
<configkey>1512</configkey>
<priority>MAJOR</priority>
<name>destructor for base class 'Symbol' (Location) is not virtual</name>
<description>In a final pass through all the classes, we have found a class (named in the message) that is the base class of a derivation and has a destructor but the destructor is not virtual. It is conventional for inherited classes to have virtual destructors so that it is safe to 'delete' a pointer to a base class. [19]</description>
</rule>
<rule>
<key>1513</key>
<configkey>1513</configkey>
<priority>MAJOR</priority>
<name>storage class ignored</name>
<description>A storage class (one of auto, extern, or register) was found within a class definition. The only storage classes that are significant when declaring members are static and typedef. [11, ?9.2]</description>
</rule>
<rule>
<key>1514</key>
<configkey>1514</configkey>
<priority>MAJOR</priority>
<name>Creating temporary to copy 'Type' to 'Type' (context: Context)</name>
<description>A temporary was created in order to initialize (or pass a value to or return a value to) a reference. This is suspect because any modification to the value will be a modification of this temporary. This message is not issued when initializing a const reference. [11, ?12.2]</description>
</rule>
<rule>
<key>1515</key>
<configkey>1515</configkey>
<priority>MAJOR</priority>
<name>Default constructor not available for member 'Symbol'</name>
<description>A member of a class was found that had a type for which a constructor was defined but for which a default constructor (one with no arguments) was not defined.</description>
</rule>
<rule>
<key>1516</key>
<configkey>1516</configkey>
<priority>MAJOR</priority>
<name>Data member hides inherited member 'Symbol' (Location)</name>
<description>A data member of a class happens to have the same name as a member of a base class. Was this deliberate? Identical names can cause confusion. To inhibit this message for a particular symbol or for an identifiable set of symbols use -esym().</description>
</rule>
<rule>
<key>1520</key>
<configkey>1520</configkey>
<priority>MAJOR</priority>
<name>Multiple assignment operators for class 'Symbol'</name>
<description>More than one assignment operator has been declared for a given class. For example, for class X there may have been declared:
void operator=(X); void operator=(X) const;
Which is to be used for assignment?</description>
</rule>
<rule>
<key>1521</key>
<configkey>1521</configkey>
<priority>MAJOR</priority>
<name>Multiple copy constructors for class 'Symbol'</name>
<description>For a given class, more than one function was declared that could serve as a copy constructor. Typically this means that you declared both X( X& ) and X( const X& ) for the same class. This is probably a mistake.</description>
</rule>
<rule>
<key>1522</key>
<configkey>1522</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' is an array of empty objects</name>
<description>An array (Symbol) is being allocated. Each member of the array appears to be empty. Although this is legal, it could be the result of human error. If this is deliberate policy, inhibit the message, either globally, or for this Symbol.</description>
</rule>
<rule>
<key>1524</key>
<configkey>1524</configkey>
<priority>MAJOR</priority>
<name>new in constructor for class 'Name' which has no explicit destructor</name>
<description>A call to new has been found in a constructor for a class for which no explicit destructor has been declared. A destructor was expected because how else can the storage be freed? [10, ?12.5]</description>
</rule>
<rule>
<key>1526</key>
<configkey>1526</configkey>
<priority>MAJOR</priority>
<name>Member function 'Symbol' (Location) not defined</name>
<description>A member function (named in the message) of a non-library class was not defined. This message is suppressed for unit checkout (-u option).</description>
</rule>
<rule>
<key>1527</key>
<configkey>1527</configkey>
<priority>MAJOR</priority>
<name>static member 'Symbol' (Location) not defined</name>
<description>A static data member (named in the message) of a non-library class was not defined. In addition to its declaration within the class, it must be defined in some module.</description>
</rule>
<rule>
<key>1528</key>
<configkey>1528</configkey>
<priority>MAJOR</priority>
<name>call to String does not match function template String</name>
<description>The first String of the message designates an actual function call that appeared to be the invocation of the template function identified by the second String. No match could be made between the arguments of the call and the template parameters.</description>
</rule>
<rule>
<key>1529</key>
<configkey>1529</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' not first checking for assignment to this</name>
<description>The assignment operator does not appear to be checking for assignment of the value of a variable to itself (assignment to this). Specifically PC-lint/FlexeLint is looking for one of:
if( &arg == this ) if( &arg != this ) if( this == &arg ) if( this != &arg )
as the first statement of the function.
It is important to check for a self assignment so as to know whether the old value should be subject to a delete operation. This is often overlooked by a class designer since it is counter-intuitive to assign to oneself. But through the magic of aliasing (pointers, references, function arguments) it is possible for an unsuspecting programmer to stumble into a disguised self-assignment [12, Item 17].
If you are currently using the following test
if( arg == *this)
we recommend you replace this with the more efficient:
if( &arg == this || arg == *this)</description>
</rule>
<rule>
<key>1531</key>
<configkey>1531</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' (Location) should have compared argument against sizeof(class)</name>
<description>This warning is given for either operator new or operator delete when defined as member functions of a class that is the base class of a derivation. In this case you can't be certain of the size of allocation and therefore your allocation functions should test the size parameter for equality to the sizeof the class. See Elective Note 1921 for more details.</description>
</rule>
<rule>
<key>1532</key>
<configkey>1532</configkey>
<priority>MAJOR</priority>
<name>Symbol 'Symbol' not checking argument for NULL</name>
<description>This message is given for a function operator delete which is a member function of a class that does not have a destructor. It should check for NULL because delete p where p has the NULL value will be passed in to it. See also 1922.</description>
</rule>
<rule>
<key>1533</key>
<configkey>1533</configkey>
<priority>MAJOR</priority>
<name>Repeated friend declaration for symbol 'Symbol'</name>
<description>A friend declaration for a particular symbol (class or function) was repeated in the same class. Usually this is a harmless redundancy.</description>
</rule>
<rule>
<key>1534</key>
<configkey>1534</configkey>
<priority>MAJOR</priority>
<name>static variable 'Symbol' found within inline function in header</name>
<description>A static variable (Symbol) was found within an inline function within a header file. This can be a source of error since the static variable will not retain the same value across multiple modules. Rather each module will retain its own version of the variable. If multiple modules need to use the function then have the function refer to an external variable rather than a static variable. Conversely if only one module needs to use the function then place the definition of the function within the module that requires it. [23, Item 26].</description>
</rule>
<rule>
<key>1535</key>
<configkey>1535</configkey>
<priority>MAJOR</priority>
<name>Exposing low access data through member 'Symbol'</name>
<description>A member function is returning an address being held by the indicated member symbol (presumably a pointer). The member's access (such as private or protected) is lower than the access of the function returning the address.</description>
</rule>
<rule>
<key>1536</key>
<configkey>1536</configkey>
<priority>MAJOR</priority>
<name>Exposing low access member 'Symbol'</name>
<description>-- A member function is
returning the non-const address of a member either directly or
via a reference. Moreover, the member's access (such as private
or protected) is lower than the access of the function returning
the address. For example:
class X
{
private:
int a;
public:
int *f() { return &a; }
};
This looks like a breach of the access system [12, Item 30]. You
may lower the access rights of the function, raise the
accessibility of the member or make the return value a const
pointer or reference. In the above example you could change the
function to:
const int *f() { return &a; }
</description>
</rule>
<rule>
<key>1537</key>
<configkey>1537</configkey>
<priority>MAJOR</priority>
<name>const function returns pointer data member 'Symbol'</name>
<description>A const function is behaving suspiciously. It is returning a pointer data member (or equivalently a pointer to data that is pointed to by a data member). For example, class X { int *p; int *f() const { return p; } };
Since f is supposedly const and since p is presumptively pointing to data that is logically part of class X we certainly have the potential for a security breach. Either return a pointer to const or remove the const modifier to the function. [12, Item 29 ].
Note, if a const function returns the address of a data member then a 605 (capability increase) is issued.</description>
</rule>
<rule>
<key>1538</key>
<configkey>1538</configkey>
<priority>MAJOR</priority>
<name>base class 'Name' absent from initializer list for copy constructor</name>
<description>The indicated base class did not appear in the initializer list for a copy constructor. Was this an oversight? If the initializer list does not contain an initializer for a base class, the default constructor is used for the base class. This is not normally appropriate for a copy constructor. The following is more typical: class B { ... }; class D : public B { D( const D &arg ) : B( arg ) { ... } ... };</description>
</rule>
<rule>
<key>1539</key>
<configkey>1539</configkey>
<priority>MAJOR</priority>
<name>member 'Symbol' (Location) not assigned by assignment operator</name>
<description>The indicated Symbol was not assigned by an assignment operator. Was this an oversight? It is not strictly necessary to initialize all members in an assignment operator because the 'this' class is presumably already initialized. But it is easy to overlook the assignment of individual members. It is also easy to overlook your responsibility to assign base class members. This is not done for you automatically. [12, Item 16]
The message is not given for const members or reference members. If you have a member that is deliberately not initialized you may suppress the message for that member only using -esym.</description>
</rule>
<rule>
<key>1540</key>
<configkey>1540</configkey>
<priority>MAJOR</priority>
<name>pointer member 'Symbol' (Location) neither freed nor zero'ed by destructor</name>
<description>The indicated member is a non-static pointer member of a class that was apparently not freed by the class' destructor. Was this an oversight? By freeing, we mean either a call to the free() function or use of the delete operator. If the pointer is only intended to point to static information during its lifetime then, of course, it never should be freed. In that case you should signal closure by assigning it the NULL pointer (0).</description>
</rule>
<rule>
<key>1541</key>
<configkey>1541</configkey>
<priority>MAJOR</priority>
<name>member 'Symbol' (Location) possibly not initialized by constructor</name>
<description>The indicated member symbol may not have been initialized by a constructor. Was this an oversight? Some of the paths that the constructor takes do initialize the member.</description>
</rule>
<rule>
<key>1542</key>
<configkey>1542</configkey>
<priority>MAJOR</priority>
<name>member 'Symbol' (Location) possibly not initialized</name>
<description>The indicated member symbol may not have been initialized prior to use. Either this is in a constructor where it is presumed that no members are pre-initialized or this is after a statement which will remove its initialization such as a delete or a free.</description>
</rule>
<rule>
<key>1543</key>
<configkey>1543</configkey>
<priority>MAJOR</priority>
<name>member 'Symbol' (Location) possibly not initialized</name>
<description>The indicated member symbol may not have been initialized prior to a point where its address is being passed to a constant pointer. This looks suspicious. Either this is in a constructor where it is presumed that no members are pre-initialized or this is after a statement which will remove its initialization such as a delete or a free.</description>
</rule>
<rule>
<key>1544</key>
<configkey>1544</configkey>
<priority>MAJOR</priority>
<name>value of variable 'Symbol' (Location) indeterminate (order of initialization)</name>
<description>A variable (identified by Symbol) was used in the run-time initialization of a static variable. However this variable itself was initialized at run-time. Since the order of initialization cannot be predicted this is the source of possible error.
Whereas addresses are completely known at initialization time values may not be. Whether the value or merely the address of a variable is used in the initialization of a second variable is not an easy thing to determine when an argument is passed by reference or via pointer. For example, class X { X( const X & ); };
extern X x1; X x2 = x1; X x1 = x2;
It is theoretically possible, but unlikely, that the constructor X() is interested only in the address of its argument and not its current value. If so, it only means you will be getting a spurious report which you can suppress based on variable name. However, if the const is missing when passing a reference parameter (or a pointer parameter) then we cannot easily assume that values are being used. In this case no report will be issued. The moral is that if you want to get the checking implied by this message you should make your constructor reference arguments const.</description>
</rule>
<rule>
<key>1545</key>
<configkey>1545</configkey>
<priority>MAJOR</priority>
<name>value of variable 'Symbol' used previously to initialize variable 'Symbol' (Location)</name>
<description>A variable identified by Symbol was used previously to initialize some other variable. This variable is now itself being initialized with run-time code. The order of these initializations cannot be predicted. See also message 1544.</description>
</rule>
<rule>
<key>1546</key>
<configkey>1546</configkey>
<priority>MAJOR</priority>
<name>direct throw of exception 'Name' within destructor 'Symbol'</name>
<description>The body of a destructor (signature provided within the message) contains a throw not within a try block. This is dangerous because destructors are themselves triggered by exceptions in sometimes unpredictable ways. The result can be a perpetual loop. [23, Item 11]</description>
</rule>
<rule>
<key>1547</key>
<configkey>1547</configkey>
<priority>MAJOR</priority>
<name>Assignment of array to pointer to base class (Context)</name>
<description>An assignment from an array of a derived class to a pointer to a base class was detected. For example: class B { }; class D : public B {}; D a[10]; B *p = a; // Warning 1547 B *q = &a[0]; // OK
In this example p is being assigned the address of the first element of an array. This is fraught with danger since access to any element other than the zeroeth must be considered an error (we presume that B and D actually have or have the potential to have different sizes). [23, Item 3].
We do not warn about the assignment to q because it appears that the programmer realizes the situation and wishes to confine q to the base object of the zeroeth element of a only. As a further precaution against inappropriate array access, out of bounds warnings are issued for subsequent references to p[1] and q[1].</description>
</rule>
<rule>
<key>1548</key>
<configkey>1548</configkey>
<priority>MAJOR</priority>
<name>Exception specification for 'Symbol' conflicts with Location</name>
<description>The exception specification of a function begins with the keyword 'throw' and follows the prototype. Two declarations were found for the same function with inconsistent exception specifications.</description>
</rule>
<rule>
<key>1549</key>
<configkey>1549</configkey>
<priority>MAJOR</priority>
<name>Exception thrown for function 'Symbol' not declared to throw</name>
<description>An exception was thrown (i.e., a throw was detected) within a function and not within a try block; moreover the function was declared to throw but the exception thrown was not on the list. If you provide an exception specification, include all the exception types you potentially will throw. [23, Item 14]</description>
</rule>
<rule>
<key>1550</key>
<configkey>1550</configkey>
<priority>MAJOR</priority>
<name>exception 'Name' thrown by function 'Symbol' is not on throw-list of function 'Symbol'</name>
<description>A function was called (first Symbol) which was declared as potentially throwing an exception. The call was not made from within a try block and the function making the call had an exception specification. Either add the exception to the list, or place the call inside a try block and catch the throw. [23, Item 14]</description>
</rule>
<rule>
<key>1551</key>
<configkey>1551</configkey>
<priority>MAJOR</priority>
<name>function may throw exception 'Name' in destructor 'Symbol'</name>
<description>A call to a function (name given by the first Symbol) was made from within a destructor. The function was declared as potentially throwing an exception. Such exceptions need to be caught within a try block because destructors should never throw exceptions. [23, Item 11].</description>
</rule>
<rule>
<key>1552</key>
<configkey>1552</configkey>
<priority>MAJOR</priority>
<name>Converting pointer to array-of-derived to pointer to base</name>
<description>This warning is similar to Warning 1547 and is sometimes given in conjunction with it. It uses value tracking to determine that an array (that could be dynamically allocated) is being assigned to a base class pointer.
For example, Derived *d = new Derived[10]; Base *b; b = d; // Warning 1552 b = &d[0]; // OK
[23, Item 3] Also, see the article by Mark Nelson (Bug++ of the Month, Windows developer's Journal, May 1997, pp. 43-44).</description>
</rule>
<rule>
<key>1553</key>
<configkey>1553</configkey>
<priority>MAJOR</priority>
<name>struct 'Symbol' declared as extern "C" contains C++ substructure 'Symbol' (Location)</name>
<description>A C++ substructure was found in a structure or class declared as extern "C". Was this intended?</description>
</rule>
<rule>
<key>1554</key>
<configkey>1554</configkey>
<priority>MAJOR</priority>
<name>Direct pointer copy of member 'Symbol' within copy constructor: 'Symbol'</name>
<description>In a copy constructor a pointer was merely copied rather than recreated with new storage. This can create a situation where two objects have the same data and this, in turn, causes problems when these objects are deleted or modified. For example, the following class will draw this warning: class X { char *p; X( const X & x ) { p = x.p; } ... };
Here, member p is expected to be recreated using new or some variant.</description>
</rule>
<rule>
<key>1555</key>
<configkey>1555</configkey>
<priority>MAJOR</priority>
<name>Direct pointer copy of member 'Symbol' within copy assignment operator: 'Symbol'</name>
<description>In a copy assignment operator a pointer was merely copied rather than recreated with new storage. This can create a situation where two objects have the same data and this, in turn, causes problems when these objects are deleted or modified. For example, the following class will draw this warning: class X { char *p; X& operator=( const X & x ) { p = x.p; } ... };
Here, member p is expected to be recreated using new or some variant.</description>
</rule>
<rule>
<key>1556</key>
<configkey>1556</configkey>
<priority>MAJOR</priority>
<name>'new Type(integer)' is suspicious</name>
<description>A new expression had the form new T(Integer) where type T has no constructor. For example:
new int(10)
will draw this warning. The expression allocates an area of storage large enough to hold one integer. It then initializes that integer to the value 10. Could this have been a botched attempt to allocate an array of 10 integers? Even if it was a deliberate attempt to allocate and initialize a single integer, a casual inspection of the code could easily lead a reader astray.
The warning is only given when the type T has no constructor. If T has a constructor then either a syntactic error will result because no constructor matches the argument or a match will be found. In the latter case no warning will or should be issued.</description>
</rule>
<rule>
<key>1557</key>
<configkey>1557</configkey>
<priority>MAJOR</priority>
<name>const member 'Symbol' is not initialized</name>
<description>A class member typed const class (or struct or union) is mentioned in a constructor initializer list. But the class (or struct or union) referenced has no constructor and hence the member is not initialized. See also messages 1558 and 1769.</description>
</rule>
<rule>
<key>1558</key>
<configkey>1558</configkey>
<priority>MAJOR</priority>
<name>virtual coupled with inline is an unusual combination</name>
<description>The function declared both 'virtual' and 'inline' has been detected. An example of such a situation is as follows: class C { virtual inline void f(); // Warning 1558 }; Virtual functions by their nature require an address and so inlining such a function seems contradictory. We recommend that the 'inline' function specifier be removed.</description>
</rule>
<rule>
<key>1559</key>
<configkey>1559</configkey>
<priority>MAJOR</priority>
<name>Uncaught exception 'Name' may be thrown in destructor 'Symbol'</name>
<description>The named exception occurred within a try block and was either not caught by any handler or was caught but then thrown from the handler. Destructors should normally not throw exceptions [23, Item 11].</description>
</rule>
<rule>
<key>1560</key>
<configkey>1560</configkey>
<priority>MAJOR</priority>
<name>Uncaught exception 'Name' not on throw-list of function 'Symbol'</name>
<description>A direct or indirect throw of the named exception occurred within a try block and was either not caught by any handler or was rethrown by the handler. Moreover, the function has an exception specification and the uncaught exception is not on the list. Note that a function that fails to declare a list of thrown exceptions is assumed to potentially throw any exception.</description>
</rule>
<rule>
<key>1561</key>
<configkey>1561</configkey>
<priority>MAJOR</priority>
<name>Reference initialization causes loss of const/volatile integrity (Context)</name>
<description>A reference initialization is resulting in a capability gain that can cause a loss of const or volatile integrity.
Typically the message is given on initializing a non-const reference with a const. For example: void f( int &x ); const int n = 0; ... f(n); Here, function f() could assign a value to its argument and thereby modify n which is declared to be const.
The message can also be issued when a pointer is initialized. Consider the following example. void h( const int *&q ); int *p; ... h(p); It might seem that passing a regular (i.e., non-const) pointer to a const int * could cause no harm. That would be correct if it were not for the reference. If function h() were to assign a pointer to const to its parameter q then upon return from the call, p could be used to modify const data.
There are many subtle cases that can boggle the mind. See the commentary to Message 605.</description>
</rule>
<rule>
<key>1562</key>
<configkey>1562</configkey>
<priority>MAJOR</priority>
<name>Exception specification for 'Symbol' is not a subset of 'Symbol' (Location)</name>
<description>The first symbol is that of an overriding virtual function for the second symbol. The exception specification for the first was found not to be a subset of the second. For example, it may be reasonable to have: struct B { virtual void f() throw(B); }; struct D:B { virtual void f() throw(D); }; Here, although the exception specification is not identical, the exception D is considered a subset of the base class B.
It would not be reasonable for D::f() to throw an exception outside the range of those thrown by B::f() because in general the compiler will only see calls to B::f() and it should be possible for the compiler to deduce what exceptions could be thrown by examining the static call.</description>
</rule>
<rule>
<key>1563</key>
<configkey>1563</configkey>
<priority>MAJOR</priority>
<name>Suspicious third argument to ?: operator</name>
<description>The third argument to ?: contained an unparenthesized assignment operator such as p ? a : b = 1 If this is what was intended you should parenthesize the third argument as in: p ? a : (b = 1) Not only is the original form difficult to read but C, as opposed to C++, would parse this as: (p ? a : b) = 1</description>
</rule>
<rule>
<key>1564</key>
<configkey>1564</configkey>
<priority>MAJOR</priority>
<name>Assigning a non-zero-one constant to a bool</name>
<description>The following looks suspicious. bool a = 34; Although there is an implicit conversion from integral to bool and assigning an integer varaible to a bool to obtain its Boolean meaning is legitimate, assigning an integer such as this looks suspicious. As the message suggests, the warning is not given if the value assigned is either 0 or 1. An Elective Note would be raised in that instance.</description>
</rule>
<rule>
<key>1565</key>
<configkey>1565</configkey>
<priority>MAJOR</priority>
<name>member 'Symbol' (Location) not assigned by initializer function</name>
<description>A function dubbed 'initializer' by a -sem option is not initializing (i.e., assigning to) every data member of a class. Reference members and const members theoretically can only be initialized via the constructor so that these members are not candidates for this message.</description>
</rule>
<rule>
<key>1566</key>
<configkey>1566</configkey>
<priority>MAJOR</priority>
<name>member 'Symbol' (Location) might have been initialized by a separate function but no '-sem(Name,initializer)' was seen</name>
<description>A class data member (whose name and location are indicated in the message) was not directly initialized by a constructor. It may have been initialized by a separately called member function. If this is the case you may follow the advice given in the message and use a semantic option to inform PC-lint/FlexeLint that the separately called function is in fact an 'initializer'. For example: class A { int a; public: void f(); A() { f(); } }; Here f() is presumably serving as an initializer for the constructor A::A(). To inform PC-lint/FlexeLint of this situation, use the option: -sem( A::f, initializer ) This will suppress Warning 1566 for any constructor of class A that calls A::f.</description>
</rule>
<rule>
<key>1567</key>
<configkey>1567</configkey>
<priority>MAJOR</priority>
<name>Initialization of variable 'Symbol' (Location) is indeterminate as it uses variable 'Symbol' through calls: 'String'</name>
<description>A variable was dynamically initialized using an expression that contained a call to a function and that function referenced a variable that was also dynamically initialized and was in some other module. For example: a.cpp: b.cpp:
int g(void); int f(void); int y = g(); int x = f(); int f() { return y; } The initialization of both x and y are dynamic. Although the order of dynamic initialization within a module is pre-ordained the order in which modules are initialized is not. Therefore it is perfectly possible for b.cpp to be initialized before a.cpp. Thus when the call is made upon function f() to initialize x, variable y may not yet have been initialized.</description>
</rule>
<rule>
<key>1568</key>
<configkey>1568</configkey>
<priority>MAJOR</priority>
<name>Variable 'Symbol' (Location) accesses variable 'Symbol' before the latter is initialized through calls: 'String'</name>
<description>A variable was dynamically initialized using an expression that contained a call to a function and that function referenced a variable that was also dynamically initialized but later in the module. For example: int g(void); int f(void); int x = f(); int y = g(); int f() { return y; } The initialization of both x and y are dynamic. The order of dynamic initialization within a module is in the order in which the initialization is specified. Thus when the call is made upon function f() to initialize x, variable y will not yet have been initialized.</description>
</rule>
<rule>
<key>1569</key>
<configkey>1569</configkey>
<priority>MAJOR</priority>
<name>Initializing a member reference with a temporary.</name>
<description>A member reference was initialized with a temporary. For example: struct A { int &n; A() : n(3) {} }; The constructor A() contains an initializer list within which it initializes n. But n will be bound to a temporary created by the compiler to hold the value 3. The lifetime of this temporary is limited; it "persists until the constructor exits" [10 section class.temporary]</description>
</rule>
<rule>
<key>1570</key>
<configkey>1570</configkey>
<priority>MAJOR</priority>
<name>Initializing a reference class member with an auto variable 'Symbol'</name>
<description>In a constructor initializer, a reference class member is being initialized to bind to an auto variable. Consider: class X { int &n; X(int k) :n(k) {} }; In this example member n is being bound to variable k which, although a parameter, is nonetheless placed into auto storage. But the lifetime of k is only the duration of the call to the constructor, whereas the lifetime of n is the lifetime of the class object constructed.</description>
</rule>
<rule>
<key>1571</key>
<configkey>1571</configkey>
<priority>MAJOR</priority>
<name>Returning an auto variable 'Symbol' via a reference type</name>
<description>A function that is declared to return a reference is returning an auto variable (that is not itself a reference). The auto variable is not guaranteed to exist beyond the lifetime of the function. This can result in unreliable and unpredictable behavior.</description>
</rule>
<rule>
<key>1572</key>
<configkey>1572</configkey>
<priority>MAJOR</priority>
<name>Initializing a static reference variable with an auto variable 'Symbol'</name>
<description>A static variable has a lifetime that will exceed that of the auto variable that it has been bound to. Consider void f( int n ) { static int& r = n; ... } The reference r will be permanently bound to an auto variable n. The lifetime of n will not extend beyond the life of the function. On the second and subsequent calls to function f the static variable r will be bound to a non-existent entity.</description>
</rule>
<rule>
<key>1573</key>
<configkey>1573</configkey>
<priority>MAJOR</priority>
<name>Generic function template 'Symbol' declared in namespace associated with type 'Symbol' (Location)</name>
<description>When a class (or union or enum) is declared within a namespace that namespace is said to be associated with the type. A Generic function template is any that has as parameters only intrinsic types or plain template arguments possibly adorned with reference or const or volatile qualification. Consider namespace X { template< class T > void f( int, const T& ); // Generic class A{}; // Warning 1573 } A call to function f that contained an argument of type X::A would, by ADL (Argument Dependent Lookup), need to also consider function X::f even though this function was not in the scope of the call. In the past this has led to strange an unexpected results.
Some designers adopt the strategy of embedding the class within a sub namespace and employing a using-declaration to make it available to users of the original namespace. For example: namespace X { template< class T > void f( int, const T& ); // Generic namespace X1 { class A{}; // No Warning } using X1::A; } Now an argument of type X::A will not automatically trigger a consideration of X::f.</description>
</rule>
<rule>
<key>1574</key>
<configkey>1574</configkey>
<priority>MAJOR</priority>
<name>Returning the address of an auto variable indirectly through reference variable 'Symbol'</name>
<description>Within a function whose return type is reference to some type, a return statement is returning a reference which has been initialized (possibly indirectly) with an auto variable. For example: int &f( int k ) { int &r = k; return r; }</description>
</rule>
<rule>
<key>1576</key>
<configkey>1576</configkey>
<priority>MAJOR</priority>
<name>Explicit specialialization does not occur in the same file as corresponding function template 'Symbol' (Location)</name>
<description>An explicit specialization of a function template was found to be declared in a file other than the one in which the corresponding function template is declared. Two identical calls in two different modules on the same function template could then have two differing interpretations based on the inclusion of header files. The result is undefined behavior.
As if this wasn't enough, if the explicit specialization could match two separate function templates then the result you obtain could depend on which function templates are in scope.
See also the next message.</description>
</rule>
<rule>
<key>1577</key>
<configkey>1577</configkey>
<priority>MAJOR</priority>
<name>Partial or explicit specialialization does not occur in the same file as primary template 'Symbol' (Location)</name>
<description>There is a danger in declaring an explicit specialization or a partial specialization in a file other than that which holds the primary class template. The reason is that a given implicit specialization will differ depending on what headers it sees. It can easily differ from module to module and undefined behavior can be the result.
See also Warning 1576 which diagnoses a similar problem with function templates.</description>
</rule>
<rule>
<key>1578</key>
<configkey>1578</configkey>
<priority>MAJOR</priority>
<name>Pointer member 'Symbol' (Location) neither freed nor zeroed by cleanup function</name>
<description>The indicated member is a non-static data member of a class that was apparently not cleared by a function that had previously been given the cleanup semantic. By clearing we mean that the pointer was either zeroed or the storage associated with the pointer released via the free function or its semantic equivalent or some form of delete. See also Warning 1540.</description>
</rule>
<rule>
<key>1579</key>
<configkey>1579</configkey>
<priority>MAJOR</priority>
<name>Pointer member 'Symbol' (Location) might have been freed by a separate function but no '-sem(Name,cleanup)' was seen</name>
<description>A class data member (whose name and location are indicated in the message) was not directly freed by the class destructor. There was a chance that it was cleared by a separately called member function. If this is the case you may follow the advice given in the message and use a semantic option to inform PC-lint/FlexeLint that the separately called function is in fact a 'cleanup' function. For example: class A { int *p; public: void release_ptrs(); ~A() { release_ptrs(); } }; Here release_ptrs() is presumably serving as a cleanup function for the destructor ~A::A(). To inform PC-lint/FlexeLint of this situation, use the option: -sem( A::release_ptrs, cleanup ) A separate message (Warning 1578) will be issued if the cleanup function fails to clear all pointers. See also Warning 1566.</description>
</rule>
<rule>
<key>1701</key>
<configkey>1701</configkey>
<priority>MINOR</priority>
<name>redundant access-specifier 'String'</name>
<description>The given access specifier (one of 'public', 'private' or 'protected') has been repeated. [11, ?11.1]</description>
</rule>
<rule>
<key>1702</key>
<configkey>1702</configkey>
<priority>MINOR</priority>
<name>operator 'Name' is both an ordinary function 'String' and a member function 'String'</name>
<description>In attempting to resolve the definition of an operator it was found that the same operator was declared as both a member function and a non-member function. Was this intended? Symmetric binary operators (such as '+', '-', '==', '>', etc.) are usually defined external to a class definition so that they can support non-objects on the left hand side. [11, ?13.4.2]</description>
</rule>
<rule>
<key>1703</key>
<configkey>1703</configkey>
<priority>MINOR</priority>
<name>Function 'String' arbitrarily selected. Refer to Error 'Integer'</name>
<description>This informational message is given with error numbers 1023, 1024, 1025 and 1026. These are issued when an error is encountered during the overload resolution process, and is issued merely to indicate which function was arbitrarily selected. [11, ?13.2]</description>
</rule>
<rule>
<key>1704</key>
<configkey>1704</configkey>
<priority>MINOR</priority>
<name>Constructor 'Symbol' has private access specification</name>
<description>A private constructor is legal and has its uses but can also result in messages that are difficult to interpret. If you use private constructors as a programming technique then you may suppress this message with a -e1704. But it's probably better to suppress this on a constructor by constructor basis using -esym.</description>
</rule>
<rule>
<key>1705</key>
<configkey>1705</configkey>
<priority>MINOR</priority>
<name>static class members may be accessed by the scoping operator</name>
<description>A static class member was accessed using a class object and -> or . notation. For example:
s.member or p->member
But an instance of the object is not necessary. It could just as easily have been referenced as:
X::member
where X is the class name. [10, ?9.4]</description>
</rule>
<rule>
<key>1706</key>
<configkey>1706</configkey>
<priority>MINOR</priority>
<name>Declaration with scope operator is unusual within a class</name>
<description>Class members within a class are not normally declared with the scope operator. For example:
class X { int X::n; ...
will elicit this message. If the (redundant) class specification (X::) were replaced by some different class specification and the declaration was not friend an error (1040) would be issued. [11, ?9.2]</description>
</rule>
<rule>
<key>1707</key>
<configkey>1707</configkey>
<priority>MINOR</priority>
<name>static assumed for String</name>
<description>operator new() and operator delete(), when declared as member functions, should be declared as static. They do not operate on an object instantiation (implied this pointer). [11, ?12.5]</description>
</rule>
<rule>
<key>1708</key>
<configkey>1708</configkey>
<priority>MINOR</priority>
<name>typedef 'Symbol' not declared as "C" conflicts with Location</name>
<description>A typedef symbol which was previously declared as extern "C" was not so declared at the current location. This is not considered as serious a situation as is indicated by message 1065 which is given for external function and variable names. If this is your programming style you may suppress this message.</description>
</rule>
<rule>
<key>1709</key>
<configkey>1709</configkey>
<priority>MINOR</priority>
<name>typedef 'Symbol' declared as "C" conflicts with Location</name>
<description>A typedef symbol was previously not declared as extern "C" but is so declared at the current location. This is not considered as serious a situation as is indicated by message 1066 which is given for external function and variable names. If this is your programming style you may suppress this message.</description>
</rule>
<rule>
<key>1710</key>
<configkey>1710</configkey>
<priority>MINOR</priority>
<name>An implicit 'typename' was assumed</name>
<description>This message is issued when the standard requires the use of 'typename' to disambiguate the syntax within a template where it may not be clear that a name is the name of a type or some non-type. (See C++ Standard [10], Section 14.6, Para 2). Consider: template< class T > class A { T::N x; // Info 1710 }; Many compilers will accept this construct since the only interpretation consistent with valid syntax is that T::N represents a type. (But if the 'x' weren't there it would be taken as an access declaration and more frequently would be a non-type).</description>
</rule>
<rule>
<key>1711</key>
<configkey>1711</configkey>
<priority>MINOR</priority>
<name>class 'Symbol' (Location) has a virtual function but is not inherited</name>
<description>The given class has a virtual function but is not the base class of any derivation. Was this a mistake? There is no advantage to making member functions virtual unless their class is the base of a derivation tree. In fact, there is a disadvantage because there is a time and space penalty for virtual functions. This message is not given for library classes and is suppressed for unit checkout. [13, ?4]</description>
</rule>
<rule>
<key>1712</key>
<configkey>1712</configkey>
<priority>MINOR</priority>
<name>default constructor not defined for class 'Name'</name>
<description>A class was defined with one or more constructors but none of these could be used as a (0 argument) default constructor. Is this an omission? The default constructor is used in declarations and for new when no explicit initialization is given. It is also used when the class is a base class and no mem-initializer is given. It is used for arrays as well. A default constructor should therefore be omitted only for good reason. If you have such a good reason for class X you can employ option -esym(1712,X). [19]</description>
</rule>
<rule>
<key>1713</key>
<configkey>1713</configkey>
<priority>MINOR</priority>
<name>Parentheses have inconsistent interpretation</name>
<description>An expression of the form: new T() is supposed to produce a default initialized allocation of type T. If T is a POD type (Plain Old Data type) it is supposed to be initialized to 0. Since this change was made relatively late in the draft leading to the standard, many compilers do not yet support this construct. If your compiler does support the construct and you have no intention of porting your application to any other compiler, suppress this message. Alternatively, code this as: new T and initialize the result explicitly.</description>
</rule>
<rule>
<key>1714</key>
<configkey>1714</configkey>
<priority>MINOR</priority>
<name>Member function 'Symbol' (Location) not referenced</name>
<description>A member function was not referenced. This message is automatically suppressed for unit checkout (-u) and for members of a library class.</description>
</rule>
<rule>
<key>1715</key>
<configkey>1715</configkey>
<priority>MINOR</priority>
<name>static member 'Symbol' (Location) not referenced</name>
<description>A static data member of a class was not referenced. This message is automatically suppressed for unit checkout (-u) and for members of a library class.</description>
</rule>
<rule>
<key>1716</key>
<configkey>1716</configkey>
<priority>MINOR</priority>
<name>Virtual member function 'Symbol' (Location) not referenced</name>
<description>A virtual member function was apparently not referenced. Not only was the function itself not referenced but the function or functions that it overrides were not referenced either. The message is not given if the member function itself or any member function that it overrides is a library member function. This is because the original virtual function may be called implicitly by the library.
This message is suppressed for unit checkout (-u).</description>
</rule>
<rule>
<key>1717</key>
<configkey>1717</configkey>
<priority>MINOR</priority>
<name>empty prototype for function declaration, assumed '(void)'</name>
<description>An empty prototype, as in:
void f();
has a different meaning in C than in C++. In C it says nothing about the arguments of the function; in C++, it says there are no arguments. This message is not given for member function declarations or for function definitions. Rather, weaker Elective Notes (1917 and 1918) are given. This is because the chance of ambiguity does not exist in these cases. [11, ?8.2.5]</description>
</rule>
<rule>
<key>1718</key>
<configkey>1718</configkey>
<priority>MINOR</priority>
<name>expression within brackets ignored</name>
<description>In the expression:
delete [ expression ] p
the expression is ignored. The expression is a vestige of an earlier time when this information provided a count of the number of items in the array being released. Note that empty square brackets are considered necessary for deleting an array. This is a complaint directed toward the expression within the brackets not the brackets themselves. [11, ?5.3.4]</description>
</rule>
<rule>
<key>1719</key>
<configkey>1719</configkey>
<priority>MINOR</priority>
<name>assignment operator for class 'Symbol' has non-reference parameter</name>
<description>The typical assignment operator for a class is of the form:
X& operator =(const X &)
If the argument is not a reference then your program is subject to implicit function calls and less efficient operation. [11, ?13.4.3]</description>
</rule>
<rule>
<key>1720</key>
<configkey>1720</configkey>
<priority>MINOR</priority>
<name>assignment operator for class 'Symbol' has non-const parameter</name>
<description>The typical assignment operator for a class is of the form:
X& operator =(const X &)
If the argument is not const then your program will not be diagnosed as completely as it might otherwise be. [11, ?13.4.3]</description>
</rule>
<rule>
<key>1721</key>
<configkey>1721</configkey>
<priority>MINOR</priority>
<name>operator =() for class 'Symbol' is not assignment operator</name>
<description>The assignment operator for a class has the form:
X& operator =(const X &)
A member function whose name is operator =, but which doesn't have that form, is not an assignment operator. This could be a source of subtle confusion for a program reader. If this is not an error you may selectively suppress this message for the given class. [11, ?13.4.3]</description>
</rule>
<rule>
<key>1722</key>
<configkey>1722</configkey>
<priority>MINOR</priority>
<name>assignment operator for class 'Symbol' does not return a reference to class</name>
<description>The typical assignment operator for a class X is of the form:
X& operator =(const X &)
The reason for returning a reference to class is to support multiple assignment as in:
a = b = c
[11, ?13.4.3]</description>
</rule>
<rule>
<key>1724</key>
<configkey>1724</configkey>
<priority>MINOR</priority>
<name>Argument to copy constructor for class 'Symbol' should be a const reference</name>
<description>A copy constructor for class X is typically declared as:
X( const X & );
If you leave off the 'const' then some diagnostics will not be possible. [19]</description>
</rule>
<rule>
<key>1725</key>
<configkey>1725</configkey>
<priority>MINOR</priority>
<name>class member 'Symbol' is a reference</name>
<description>There are a number of subtle difficulties with reference data members. If a class containing a reference is assigned, the default assignment operator will presumably copy the raw underlying pointer. This violates the principle that a reference's underlying pointer, once established, is never modified. Some compilers protect against this eventuality by refusing to create a default assignment operator for classes containing references. Similar remarks can be made about copy constructors. If you are careful about how you design your copy constructors and assignment operators, then references within classes can be a useful programming technique. They should not, however, be employed casually. [21, ?2.1.3]</description>
</rule>
<rule>
<key>1726</key>
<configkey>1726</configkey>
<priority>MINOR</priority>
<name>taking address of overloaded function name 'Symbol'</name>
<description>A reference is being made to an overloaded function without an immediately following '('. Thus there is no argument list to distinguish which function is intended. Resolution of the overloaded name can only be made by analyzing the destination. Is this what the programmer intended? [11, ?13.3]</description>
</rule>
<rule>
<key>1727</key>
<configkey>1727</configkey>
<priority>MINOR</priority>
<name>inline 'Symbol' not previously defined inline at (Location)</name>
<description>A function declared or defined inline was not previously declared inline. Was this intended? If this is your standard practice then suppress this message. [11, ?9.3.2]</description>
</rule>
<rule>
<key>1728</key>
<configkey>1728</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' was previously defined inline at (Location)</name>
<description>A function was previously declared or defined inline. The inline modifier is absent from the current declaration or definition. Was this intended? If this is your standard practice then suppress this message. [11, ?9.3.2]</description>
</rule>
<rule>
<key>1729</key>
<configkey>1729</configkey>
<priority>MINOR</priority>
<name>Initializer inversion detected for member 'Symbol'</name>
<description>In a constructor initializer the order of evaluation is determined by the member order not the order in which the initializers are given. At least one of the initializers was given out of order. Was there a reason for this? Did the programmer think that by changing the order that he/she would affect the order of evaluation? Place the initializers in the order of their occurrence within the class so that there can be no mistaken assumptions. [12, Item 13]</description>
</rule>
<rule>
<key>1730</key>
<configkey>1730</configkey>
<priority>MINOR</priority>
<name>class/struct inconsistency for symbol 'Symbol' (conflicts with Location)</name>
<description>An object is declared both with the keyword class and with the keyword struct. Though this is legal it is suspect. [11, ?7.1.6]</description>
</rule>
<rule>
<key>1732</key>
<configkey>1732</configkey>
<priority>MINOR</priority>
<name>new in constructor for class 'Name' which has no assignment operator</name>
<description>Within a constructor for the cited class, there appeared a new. However, no assignment operator was declared for this class. Presumably some class member (or members) points to dynamically allocated memory. Such memory is not treated properly by the default assignment operator. Normally a custom assignment operator would be needed. Thus, if x and y are both of type Symbol
x = y;
will result in pointer duplication. A later delete would create chaos. [12, Item 11]</description>
</rule>
<rule>
<key>1733</key>
<configkey>1733</configkey>
<priority>MINOR</priority>
<name>new in constructor for class 'Name' which has no copy constructor</name>
<description>Within a constructor for the cited class, there appeared a new. However, no copy constructor was declared for this class. Presumably, because of the new, some class member (or members) points to dynamically allocated memory. Such memory is not treated properly by the default copy constructor. Normally a custom copy constructor would be needed. [12, Item 11]</description>
</rule>
<rule>
<key>1734</key>
<configkey>1734</configkey>
<priority>MINOR</priority>
<name>Had difficulty compiling template function: 'Symbol'</name>
<description>At template wrap-up time where there is an attempt to 'compile' each template function according to arguments provided, the cited function could not be processed fully. The difficulty may be the result of syntax errors cited earlier and if these errors are repaired then this message should go away.</description>
</rule>
<rule>
<key>1735</key>
<configkey>1735</configkey>
<priority>MINOR</priority>
<name>Virtual function 'Symbol' has default parameter</name>
<description>A virtual function was detected with a default parameter. For example: class B { virtual void f( int n = 5 ); ... };
The difficulty is that every virtual function f overriding this virtual function must contain a default parameter and its default parameter must be identical to that shown above. If this is not done, no warnings are issued but behavior may have surprising effects. This is because when f() is called through a base class pointer (or reference) the function is determined from the actual type (the dynamic type) and the default argument is determined from the nominal type (the static type). [12, Item 38].</description>
</rule>
<rule>
<key>1736</key>
<configkey>1736</configkey>
<priority>MINOR</priority>
<name>Redundant access specifier (String)</name>
<description>An access specifier (one of public, private, or protected as shown in String) is redundant. That is, the explicitly given access specifier did not have to be given because an earlier access specifier of the same type is currently active. This message is NOT given for an access specifier that is the first item to appear in a class definition. Thus class abc { private: ...
does not draw this message. The reason this message is issued is because it is very easy to make the following mistake. class A { public: // declare private members: ... public: // declare public members: ...
In general there are no compiler warnings that would result from such an unintentional botch.</description>
</rule>
<rule>
<key>1737</key>
<configkey>1737</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' hides global operator new</name>
<description>The indicated Symbol is a class member operator new. It is not compatible with the global operator new and, moreover, no other operator new within the class is argument list compatible with the global operator new. For this reason the user of these classes will get a surprise if he/she calls for new X where X is the class name. It will be greeted with an error. The solution is to define a single argument operator new as a class member. [12, Item 9].</description>
</rule>
<rule>
<key>1738</key>
<configkey>1738</configkey>
<priority>MINOR</priority>
<name>non-copy constructor 'Symbol' used to initialize copy constructor</name>
<description>In an initializer list for a copy constructor, a base class constructor was invoked. However, this base class constructor was not itself a copy constructor. We expect that copy constructors will invoke copy constructors. Was this an oversight or was there some good reason for choosing a different kind of constructor? If this was deliberate, suppress this message. See also message 1538.</description>
</rule>
<rule>
<key>1739</key>
<configkey>1739</configkey>
<priority>MINOR</priority>
<name>Binary operator 'Symbol' should be non-member function</name>
<description>The indicated function was declared as a member function. There were a number of indicators to suggest that it should have been a non-member function. The class, X of which it was a member has a constructor that could be used to convert numeric values to X. The parameter to the operator was X or its equivalent. For this reason the operator would behave unsymmetrically. A numeric value on the right hand side would be promoted but not a value on the left hand side. For example, X op 27 would work but 27 op X would not. [12, Item 19].</description>
</rule>
<rule>
<key>1740</key>
<configkey>1740</configkey>
<priority>MINOR</priority>
<name>pointer member 'Symbol' (Location) not directly freed or zero'ed by destructor</name>
<description>A destructor did not free or zero a pointer member. However, it did call out to another (non-const) member function which may have done the required work. This Informational message is a companion to Warning 1540 which covers the situation where no member function is called from within the destructor.</description>
</rule>
<rule>
<key>1741</key>
<configkey>1741</configkey>
<priority>MINOR</priority>
<name>member 'Symbol' (Location) conceivably not initialized by constructor</name>
<description>The indicated member symbol may not have been initialized by a constructor. Was this an oversight? There appears to be a path through a loop that does initialize the member and the warning is issued because it is not clear that the loop is always executed at least once.</description>
</rule>
<rule>
<key>1742</key>
<configkey>1742</configkey>
<priority>MINOR</priority>
<name>member 'Symbol' (Location) conceivably not initialized</name>
<description>The indicated member symbol conceivably may not have been initialized by a constructor. Was this an oversight? Some of the execution paths that the constructor takes, do initialize the member.</description>
</rule>
<rule>
<key>1743</key>
<configkey>1743</configkey>
<priority>MINOR</priority>
<name>member 'Symbol' (Location) conceivably not initialized</name>
<description>The indicated member symbol conceivably may not have been initialized prior to use. Either this is in a constructor where it is presumed that no members are pre-initialized or this is after a statement which will remove its initialization such as a delete or a free.</description>
</rule>
<rule>
<key>1744</key>
<configkey>1744</configkey>
<priority>MINOR</priority>
<name>member 'Symbol' (Location) possibly not initialized by private constructor</name>
<description>The designated member was possibly not initialized by a private constructor. This message is similar to messages 1401, 1541 and 1741 which are given for ordinary (non private) constructors. It is given a special error number because a private constructor may be one that, by design, is never called and variables may be deliberately left uninitialized. In that case this message should be suppressed.</description>
</rule>
<rule>
<key>1745</key>
<configkey>1745</configkey>
<priority>MINOR</priority>
<name>member 'Symbol' (Location) not assigned by private assignment operator</name>
<description>The indicated Symbol was not assigned by a private assignment operator. This is very much like Warning 1539 except that the assignment operator in question is private. A private assignment operator may simply be a device to thwart unintended use of the assignment operator. In this case you may not care about unassigned members. If this is so, suppress this message.
The message is not given for const members or reference members. [12, Item 16]</description>
</rule>
<rule>
<key>1746</key>
<configkey>1746</configkey>
<priority>MINOR</priority>
<name>parameter 'Symbol' of function 'Symbol' could be made const reference</name>
<description>The indicated parameter is a candidate to be declared as a const reference. For example: void f( X x ) { // x not modified. }
Then the function definition can be replaced with: void f( const X &x ) { // x not modified. }
The result is more efficient since less information needs to be placed onto the stack and a constructor need not be called.
The message is only given with class-like arguments (including struct's and union's) and only if the parameter is not subsequently modified or potentially modified by the function. The parameter is potentially modified if it is passed to a function whose corresponding parameter is a reference (not const) or if its address is passed to a non-const pointer. [12, Item 22].</description>
</rule>
<rule>
<key>1747</key>
<configkey>1747</configkey>
<priority>MINOR</priority>
<name>binary operator 'Symbol' returning a reference</name>
<description>An operator-like function was found to be returning a reference. For example: X &operator+ ( X &, X & );
This is almost always a bad idea. [12, Item 23]. You normally can't return a reference unless you allocate the object, but then who is going to delete it. The usual way this is declared is: X operator+ ( X &, X & );</description>
</rule>
<rule>
<key>1748</key>
<configkey>1748</configkey>
<priority>MINOR</priority>
<name>non-virtual base class 'Name' included twice in class 'Name'</name>
<description>Through indirect means, a given class was included at least twice as a base class for another class. At least one of these is not virtual. Although legal, this may be an oversight. Such base classes are usually marked virtual resulting in one rather than two separate instances of the base class. This is done for two reasons. First, it saves memory; second, references to members of such a base class will not be ambiguous.</description>
</rule>
<rule>
<key>1749</key>
<configkey>1749</configkey>
<priority>MINOR</priority>
<name>base class 'Symbol' of class 'Symbol' need not be virtual</name>
<description>The designated base class is a direct base class of the second class and the derivation was specified as 'virtual'. But the base class was not doubly included (using this link) within any class in the entire project. Since a virtual link is less efficient than a normal link this may well be an unenlightened use of 'virtual'. [23, Item 24]. The message is inhibited if unit checkout (-u) is selected.</description>
</rule>
<rule>
<key>1750</key>
<configkey>1750</configkey>
<priority>MINOR</priority>
<name>local template 'Symbol' (Location) not referenced</name>
<description>A 'local' template is one that is not defined in a header file. The template was not used in the module in which it was defined.</description>
</rule>
<rule>
<key>1752</key>
<configkey>1752</configkey>
<priority>MINOR</priority>
<name>catch parameter Integer is not a reference</name>
<description>This message is issued for every catch parameter that is not a reference and is not numeric. The problem with pointers is a problem of ownership and delete responsibilities; the problem with a non-ref object is the problem of slicing away derivedness [23, Item 13].</description>
</rule>
<rule>
<key>1753</key>
<configkey>1753</configkey>
<priority>MINOR</priority>
<name>Overloading special operator 'Symbol'</name>
<description>This message is issued whenever an attempt is made to declare one of these operators as having some user-defined meaning: operator || operator &amp;amp;&amp;amp; operator ,
The difficulty is that the working semantics of the overloaded operator is bound to be sufficiently different from the built-in operators, as to result in possible confusion on the part of the programmer. With the built-in versions of these operators, evaluation is strictly left-to-right. With the overloaded versions, this is not guaranteed. More critically, with the built-in versions of &amp;amp;&amp;amp; and ||, evaluation of the 2nd argument is conditional upon the result of the first. This will never be true of the overloaded version. [23, Item 7].</description>
</rule>
<rule>
<key>1754</key>
<configkey>1754</configkey>
<priority>MINOR</priority>
<name>Expected symbol 'Symbol' to be declared for class 'Symbol'</name>
<description>The first Symbol is of the form: operator op= where op is a binary operator. A binary operator op was declared for type X where X is identified by the second Symbol. For example, the appearance of: X operator+( const X &, const X & );
somewhere in the program would suggest that a += version appear as a member function of class X. This is not only to fulfill reasonable expectations on the part of the programmer but also because operator+= is likely to be more efficient than operator+ and because operator+ can be written in terms of operator+=. [23, Item 22]
The message is also given for member binary operators. In all cases the message is not given unless the return value matches the first argument (this is the implicit argument in the case of a member function).</description>
</rule>
<rule>
<key>1755</key>
<configkey>1755</configkey>
<priority>MINOR</priority>
<name>global template 'Symbol' (Location) not referenced</name>
<description>A 'global' template is one defined in a header file. This message is given for templates defined in non-library header files. The template is not used in any of the modules comprising the program. The message is suppressed for unit checkout (-u).</description>
</rule>
<rule>
<key>1757</key>
<configkey>1757</configkey>
<priority>MINOR</priority>
<name>Discarded instance of post decrement/increment</name>
<description>A postfix increment or postfix decrement operator was used in a context in which the result of the operation was discarded. For example: X a;
... a++;
In such contexts it is just as correct to use prefix decrement/increment. For example this could be replaced with: X a;
... ++a;
The prefix form is (or should be) more efficient than the postfix form because, in the case of user-defined types, it should return a reference rather than a value (see 1758 and 1759). This presumes that the side effects of the postfix form are equivalent to those of the prefix form. If this is not the case then either make them equivalent (the preferred choice) or turn this message off. [23, Item 6].</description>
</rule>
<rule>
<key>1758</key>
<configkey>1758</configkey>
<priority>MINOR</priority>
<name>Prefix increment/decrement operator 'Symbol' returns a non-reference</name>
<description>To conform with most programming expectations, a prefix increment/decrement operator should return a reference. Returning a reference is both more flexible and more efficient [23, Item 6].
The expected form is as shown below: class X { X & operator++(); // prefix operator X operator++( int ); // postfix operator ... };</description>
</rule>
<rule>
<key>1759</key>
<configkey>1759</configkey>
<priority>MINOR</priority>
<name>Postfix increment/decrement operator 'Symbol' returns a reference.</name>
<description>To conform with most programming expectations, a postfix increment/decrement operator should return a value as opposed to a reference. [23, Item 6].</description>
</rule>
<rule>
<key>1760</key>
<configkey>1760</configkey>
<priority>MINOR</priority>
<name>Redundant template 'Symbol' defined identically at Location</name>
<description>A template was defined identically in the same module. Was this a mistake?</description>
</rule>
<rule>
<key>1761</key>
<configkey>1761</configkey>
<priority>MINOR</priority>
<name>Declaration of function 'Symbol' hides overloaded function 'Symbol' (Location)</name>
<description>A function declaration hides an overloaded function. This does not contribute to the overloaded-ness of the function but completely hides all the overloaded functions in some prior scope. If this is your intent suppress this message.</description>
</rule>
<rule>
<key>1762</key>
<configkey>1762</configkey>
<priority>MINOR</priority>
<name>Member function 'Symbol' could be made const</name>
<description>The indicated (non-static) member function did not modify member data and did not call non-const functions. Moreover, it does not make any deep modification to the class member. A modification is considered deep if it modifies information indirectly through a class member pointer. Therefore it could and probably should be declared as a const member function. See also Info 1763 and Elective Note 1962.</description>
</rule>
<rule>
<key>1763</key>
<configkey>1763</configkey>
<priority>MINOR</priority>
<name>Member function 'Symbol' marked as const indirectly modifies class</name>
<description>The designated symbol is a member function declared as const. Though technically valid, the const may be misleading because the member function modifies (or exposes) information indirectly referenced by the object. For example: class X { char *pc; char & get(int i) const { return pc[i]; } };
results in Info 1763 for function X::get. This is because the function exposes information indirectly held by the class X.
Experts [24] recommend that a pair of functions be made available in this situation: class X { char *pc; const char & get(int i) const { return pc[i]; } char & get(int i) { return pc[i]; } };
In this way, if the object is const then only the const function will be called which will return the protected reference. Related messages are also 1762 and 1962. See also [12, Item 29] for a further description.</description>
</rule>
<rule>
<key>1764</key>
<configkey>1764</configkey>
<priority>MINOR</priority>
<name>Reference parameter 'Symbol' (Location) could be declared const reference</name>
<description>As an example:
int f( int & k ) { return k; }
can be redeclared as:
int f( const int & k ) { return k; }
Declaring a parameter a reference to const offers advantages that a mere reference does not. In particular, you can pass constants, temporaries and const types into such a parameter where otherwise you may not. In addition it can offer better documentation.
Other situations in which a const can be added to a declaration are covered in messages 818, 952, 953 and 954.</description>
</rule>
<rule>
<key>1768</key>
<configkey>1768</configkey>
<priority>MINOR</priority>
<name>Virtual function 'Symbol' has an access (String) different from the access (String) in the base class (String)</name>
<description>An overriding virtual function has an access (public, protected or private) in the derived class different from the access of the overridden virtual function in the base class. Was this an oversight? Since calls to the overriding virtual function are usually made through the base class, making the access different is unusual (though legal).</description>
</rule>
<rule>
<key>1769</key>
<configkey>1769</configkey>
<priority>MINOR</priority>
<name>Member or base class 'Symbol' has no constructor</name>
<description>An initializer of the form Symbol() is ignored. Symbol is either a class member with a class, struct, or union type or is a base class. In either case the class (or struct or union) has no constructor and hence what appears to be an initialization is not. See also messages 1557 and 1558.</description>
</rule>
<rule>
<key>1770</key>
<configkey>1770</configkey>
<priority>MINOR</priority>
<name>function 'Symbol' defined without function 'String'</name>
<description>A typical Info 1770 message is: function 'operator new(unsigned)' defined without function 'operator delete'
There are three others: operator delete without an operator new, operator new[] without an operator delete[], and operator delete[] without an operator new[].
In general it is not a good idea to create one of these functions without the other in the pairing. [23, Item 27]
You can suppress any of these without suppressing them all. Simply do a -esym(1770,name) where name is the first function named in the message.</description>
</rule>
<rule>
<key>1771</key>
<configkey>1771</configkey>
<priority>MINOR</priority>
<name>function 'Symbol' replaces global function</name>
<description>This message is given for operator new and operator delete (and for their [] cousins) when a definition for one of these functions is found. Redefining the built-in version of these functions is not considered sound programming practice. [23, Item 27]</description>
</rule>
<rule>
<key>1772</key>
<configkey>1772</configkey>
<priority>MINOR</priority>
<name>Assignment operator 'Symbol' is not returning *this</name>
<description>The assignment operator should return *this. This is to allow for multiple assignments as in:
a = b = c;
It is also better to return the object that has just been modified rather than the argument. [12, Item 15]</description>
</rule>
<rule>
<key>1773</key>
<configkey>1773</configkey>
<priority>MINOR</priority>
<name>Attempt to cast away const (or volatile)</name>
<description>An attempt was made to cast away const. This can break the integrity of the const system. This message will be suppressed if you use const_cast. Thus: char *f( const char * p ) { if( test() ) return (char *) p; // Info 1773 else return const_cast<char *>(p); // OK }
See [12, Item 21].</description>
</rule>
<rule>
<key>1774</key>
<configkey>1774</configkey>
<priority>MINOR</priority>
<name>Could use dynamic_cast to downcast ptr to polymorphic type 'Symbol'</name>
<description>A downcast was detected of a pointer to a polymorphic type (i.e., one with virtual functions). A dynamic_cast could be used to cast this pointer safely. For example: class B { virtual ~B(); }; class D : public B {}; ... D *f( B *p ) { return dynamic_cast<D*>(p); }
In the above example, if p is not a pointer to a D then the dynamic cast will result in a NULL pointer value. In this way, the validity of the conversion can be directly tested.
B needs to be a polymorphic type in order to use dynamic_cast. If B is not polymorphic, message 1939 is issued.</description>
</rule>
<rule>
<key>1775</key>
<configkey>1775</configkey>
<priority>MINOR</priority>
<name>catch block does not catch any declared exception</name>
<description>A catch handler does not seem to catch any exceptions. For example: try { f(); } catch( B& ) {} catch( D& ) {} // Info 1775 catch( ... ) {} catch( char * ) {} // Info 1775
If f() is declared to throw type D, and if B is a public base class of D, then the first catch handler will process that exception and the second handler will never be used. The fourth handler will also not be used since the third handler will catch all exceptions not caught by the first two.
If f() is not declared to throw an exception then Info 1775 will be issued for all four catch handlers.</description>
</rule>
<rule>
<key>1776</key>
<configkey>1776</configkey>
<priority>MINOR</priority>
<name>Converting string literals to Type is not const safe (Context)</name>
<description>A string literal, according to Standard C++ is typed an array of const char. This message is issued when such a literal is assigned to a non-const pointer. For example:
char *p = "string";
will trigger this message. This pointer could then be used to modify the string literal and that could produce some very strange behavior.
Such an assignent is legal but "deprecated" by the C++ Standard. The reason for not ruling it illegal is that numerous existing functions have their arguments typed as char * and this would break working code.
Note that this message is only given for string literals. If an expression is typed as pointer to const char in some way other than via string literal, then an assignment of that pointer to a non-const pointer will receive a more severe warning.</description>
</rule>
<rule>
<key>1777</key>
<configkey>1777</configkey>
<priority>MINOR</priority>
<name>Template recursion limit (Integer) reached, use -tr_limit(n)</name>
<description>It is possible to write a recursive template that will contain a recursive invocation without an escape clause. For example:
template <class T> class A { A< A > x; }; A<int> a; This will result in attempts to instantiate: A<int> A<A<int>> A<A<A<int>>> ... Using the -vt option (turning on template verbosity) you will see the sequence in action. Accordingly we have devised a scheme to break the recursion when an arbitrary depth of recursion has been reached (at this writing 75). This depth is reported in the message. As the message suggests, this limit can be adjusted so that it equals some other value.
When the limit is reached, a complete type is not used in the definition of the last specialization in the sequence but processing goes on. The message can be suppressed in most cases with no ill effects.</description>
</rule>
<rule>
<key>1778</key>
<configkey>1778</configkey>
<priority>MINOR</priority>
<name>Assignment of string literal to variable 'Symbol' (Location) is not const safe</name>
<description>This message is issued when a string literal is assigned to a variable whose type is a non-const pointer. The name of the variable appears in the message as well as the location at which the variable was defined (or otherwise declared). For example: char *p; p = "abc"; The message is issued automatically (i.e. by default) for C++. For C, to obtain the message, you need to enable the Strings-are-Const flag (+fsc). This message is similar to message 1776 except that it is issued whenever a string constant is being assigned to a named destination.</description>
</rule>
<rule>
<key>1780</key>
<configkey>1780</configkey>
<priority>MINOR</priority>
<name>Returning address of reference parameter 'Symbol'</name>
<description>The address of a parameter that has been declared as being a reference to a const is being returned from a function. The danger of this is that the reference may designate a temporary variable that will not persist long after the call. For example: const int *f( const int & n ) { return &n; } int g(); const int *p = f( g() ); Here, p points to a temporary value whose duration is not guaranteed. If the reference is not const then you will get Elective Note 1940.
This is an example of the Linton Convention as described by Murray [21].</description>
</rule>
<rule>
<key>1781</key>
<configkey>1781</configkey>
<priority>MINOR</priority>
<name>Passing address of reference parameter 'Symbol' into caller address space</name>
<description>The address of a parameter that has been declared as being a reference to a const is being assigned to a place outside the function. The danger of this is that the reference may designate a temporary variable that will not persist long after the call. For example: void f( const int & n, const int **pp ) { *pp = &n; } int g(); const int *p; ... f( g(), &p ); Here, p will be made to point to a temporary value whose duration is not guaranteed. If the reference is not const then you will get Elective Note 1940.
This is an example of the Linton Convention as described by Murray [21].</description>
</rule>
<rule>
<key>1782</key>
<configkey>1782</configkey>
<priority>MINOR</priority>
<name>Assigning address of reference parameter 'Symbol' to a static variable</name>
<description>The address of a parameter that has been declared as being a reference to a const is being assigned to a static variable. The danger of this is that the reference may designate a temporary variable that will not persist long after the call. For example: const int *p; void f( const int & n ) { p = &n; } int g(); ... f( g() ); Here, p will be made to point to a temporary value whose duration is not guaranteed. If the reference is not const then you will get Elective Note 1940.
This is an example of the Linton Convention as described by Murray [21].</description>
</rule>
<rule>
<key>1784</key>
<configkey>1784</configkey>
<priority>MINOR</priority>
<name>Symbol 'Symbol' previously declared as "C", compare with Location</name>
<description>A symbol is being redeclared in the same module. Whereas earlier it had been declared with an extern "C" linkage, in the cited declaration no such linkage appears. E.g. extern "C" void f(int); void f(int); // Info 1784 In this case the extern "C" prevails and hence this inconsistency probably represents a benign redeclaration. Check to see which linkage is most appropriate and amend or remove the declaration in error.</description>
</rule>
<rule>
<key>1785</key>
<configkey>1785</configkey>
<priority>MINOR</priority>
<name>Implicit conversion from Boolean (Context) (Type to Type)</name>
<description>A Boolean expression was assigned (via assignment, return, argument passing or initialization) to an object of some other type. Was this the programmer's intent? The use of a cast will prevent this message from being issued.</description>
</rule>
<rule>
<key>1786</key>
<configkey>1786</configkey>
<priority>MINOR</priority>
<name>Implicit conversion to Boolean (Context) (Type to Type)</name>
<description>A non-Boolean expression was assigned (via assignment, return, argument passing or initialization) to an object of type Boolean. Was this the programmer's intent? The use of a cast will prevent this message from being issued.</description>
</rule>
<rule>
<key>1787</key>
<configkey>1787</configkey>
<priority>MINOR</priority>
<name>Access declarations are deprecated in favor of using declarations</name>
<description>The C++ standard ([10] section 7.3.3) specifically deprecates the use of access declarations. The preferred syntax is the using declaration. For example: class D : public B { B::a; // message 1787 using B::a; // preferred form produces no message };</description>
</rule>
<rule>
<key>1788</key>
<configkey>1788</configkey>
<priority>MINOR</priority>
<name>Variable 'Symbol' (Location) (type 'Name') is referenced only by its constructor or destructor</name>
<description>A variable has not been referenced other than by the constructor which formed its initial value or by its destructor or both. The location of the symbol and also its type is given in the message. For example: class A { A(); }; void f() { A a; } will produce a 1788 for variable 'a' and for type 'A'.
It very well may be that this is exactly what the programmer wants to do in which case you may suppress this message for this variable using the option -esym(1788,a). It may also be that the normal use of class A is to employ it in this fashion. That is, to obtain the effects of construction and, possibly, destruction but have no other reference to the variable. In this case the option of choice would be -esym(1788,A).</description>
</rule>
<rule>
<key>1789</key>
<configkey>1789</configkey>
<priority>MINOR</priority>
<name>Template constructor 'Symbol' cannot be a copy constructor</name>
<description>This message is issued for classes for which a copy constructor was not defined but a template constructor was defined. The C++ standard specifically states that a template constructor will not be used as a copy constructor. Hence a default copy constructor is created for such a class while the programmer may be deluded into thinking that the template will be employed for this purpose. [28, Item 5].</description>
</rule>
<rule>
<key>1790</key>
<configkey>1790</configkey>
<priority>MINOR</priority>
<name>Base class 'Symbol' has no non-destructor virtual functions</name>
<description>A public base class contained no virtual functions except possibly virtual destructors. There is a school of thought that public inheritance should only be used to interject custom behavior at the event of virtual function calls. To quote from Marshall Cline, "Never inherit publicly to reuse code (in the base class); inherit publicly in order to be reused (by code that uses base objects polymorphically)" [28, Item 22].</description>
</rule>
<rule>
<key>1791</key>
<configkey>1791</configkey>
<priority>MINOR</priority>
<name>No token on this line follows the 'return' keyword</name>
<description>A line is found that ends with a return keyword and with no other tokens following. Did the programmer forget to append a semi-colon? The problem with this is that the next expression is then consumed as part of the return statement. Your return might be doing more that you thought. For example: void f( int n, int m ) { if( n < 0 ) return // do not print when n is negative print( n ); print( m ); } Assuming print() returns void, this is entirely legal but is probably not what you intended. Instead of printing n and m, for n not negative you print just m. For n negative you print n.
To avoid this problem always follow the return keyword with something on the same line. It could be a semi-colon, an expression or, for very large expressions, some portion of an expression.</description>
</rule>
<rule>
<key>1792</key>
<configkey>1792</configkey>
<priority>MINOR</priority>
<name>Assignment operator for class 'Symbol' does not return a const reference to class</name>
<description>The typical use of an assignment operator for class C is to assign new information to variables of class C. If this were the entire story there would be no need for the assignment operator to return anything. However, it is conventional to support chains of assignment as in: C x, y, z; ... x = y = z; // parsed as x = (y = z); For this reason assignment normally returns a reference to the object assigned the value. For example, assignment (y = z) would return a reference to y.
Since it is almost never the case that this variable is to be reassigned, i.e. we almost never wish to write: (x = y) = z; // unusual as a general rule it is better to make the assignment operator return a const reference. This will generate a warning when the unusual case is attempted.
But experts differ. Some maintain that in order to support non-const member functions operating directly on the result of an assignment as in: (x = y).mangle(); where, as its name suggests, mangle is non-const it would be necessary for the return value of assignment to be non-const. Others would argue that this code could easily be replaced by a pair of expressions but if you want to support this style of programming then you should suppress this message.</description>
</rule>
<rule>
<key>1793</key>
<configkey>1793</configkey>
<priority>MINOR</priority>
<name>While calling 'Symbol': Initializing the implict object parameter 'Type' (a non-const reference) with a non-lvalue</name>
<description>A non-static and non-const member function was called and an rvalue (a temporary object) of class type was used to initialize the implicit object parameter. This is legal (and possibly intentional) but suspicious. Consider the following. struct A { void f(); }; ... A().f(); // Info 1793 ... In the above the 'non-static, non-const member function' is A::f(). The 'implicit object parameter' for the call to A::f() is A(), a temporary. Since the A::f() is non-const it presumably modifies A(). But since A() is a temporary, any such change is lost. It would at first blush appear to be a mistake.
The Standard normally disallows binding a non-const reference to an rvalue (see Error 1058 in the manual), but as a special case allows it for the binding of the implicit object parameter in member function calls. Some popular libraries take advantage of this rule in a legitimate way. For example, the GNU implementation of std::vector<bool>::operator[] returns a temporary object of type std::_Bit_reference -- a class type with a non-const member operator=(). _Bit_reference serves a dual purpose. If a value is assigned to it, it modifies the original class through its operator=(). If a value is extracted from it, it obtains that value from the original class through its operator bool().
Probably the best policy to take with this message is to examine instances of it and if this is a library invocation or a specially designed class, then suppress the message with a -esym() option.</description>
</rule>
<rule>
<key>1794</key>
<configkey>1794</configkey>
<priority>MINOR</priority>
<name>Using-declaration introduces 'Name' (Location), which has the same parameter list as 'Name' (Location), which was also introduced here by previous using-declaration 'Name' (Location)</name>
<description>This kind of scenario is perhaps best explained by way of example: struct A{}; // Library 1: namespace N { int f(const A&); int f(char*); } // Library 2: namespace Q { int f(const A&); int f(int); } // Non-library code: using N::f; using Q::f; // Info 1794 here According to the ISO Standard, 14. Added Bibliography, [34], the names of N::f(A) and Q::f(A) will coexist in the global namespace (along with the names of the other overloads of f). This alone does not make the program ill-formed. (For that you would have to make some use of the name 'f' that resulted in overload resolution where f(A) is selected.) However, a user of N and Q may be surprised to find that both library namespaces supply a function f that operates on ::A objects, and that both have been introduced into the same scope. So to avoid confusion, the user may opt to do away with the using-declarations and just refer to the various f()'s with qualified-ids.</description>
</rule>
<rule>
<key>1795</key>
<configkey>1795</configkey>
<priority>MINOR</priority>
<name>Defined template 'Symbol' was not instantiated.</name>
<description>The named template was defined but not instantiated. As such, the template either represents superfluous code or indicates a logic error.
The 'template' in the message could also be a temploid. A temploid is defined as either a template or a member of a temploid.</description>
</rule>
<rule>
<key>1796</key>
<configkey>1796</configkey>
<priority>MINOR</priority>
<name>Explicit specialization of overloaded function template 'Symbol'</name>
<description>A pair of overloaded function templates was followed by an explicit specialization. For example: template< class T > void f( T ); template< class T > void f( T* ); template<> void f( char * p ) { printf( "%s\n", p ); }
Confusion can arise in determining which of the two function templates the specialization is actually specializing. This will lead to unexpected results when processing overload resolution since the specialization does not directly compete with the templates. Both function templates compete with each other and it can be difficult to ascertain whether the specialization is invoked in any particular call.</description>
</rule>
<rule>
<key>1901</key>
<configkey>1901</configkey>
<priority>INFO</priority>
<name>Creating a temporary of type 'Symbol'</name>
<description>PC-lint/FlexeLint judges that a temporary needs to be created. This occurs, typically, when a conversion is required to a user object (i.e. class object). Where temporaries are created, can be an issue of some concern to programmers seeking a better understanding of how their programs are likely to behave. But compilers differ in this regard.</description>
</rule>
<rule>
<key>1902</key>
<configkey>1902</configkey>
<priority>INFO</priority>
<name>useless ';' follows '}' in function definition</name>
<description>It is possible to follow a function body with a useless semi-colon. This is not necessarily 'lint' to be removed but may be a preferred style of programming (as semi-colons are placed at the end of other declarations).</description>
</rule>
<rule>
<key>1904</key>
<configkey>1904</configkey>
<priority>INFO</priority>
<name>Old-style C comment</name>
<description>For the real bridge-burner one can hunt down and remove all instances of the /* ... */ form of comment. [12, Item 4]</description>
</rule>
<rule>
<key>1905</key>
<configkey>1905</configkey>
<priority>INFO</priority>
<name>implicit default constructor generated for class 'Name'</name>
<description>A default constructor was not defined for a class but a base class or a member has a non-trivial default constructor and so a non-trivial default constructor is generated for this class.</description>
</rule>
<rule>
<key>1907</key>
<configkey>1907</configkey>
<priority>INFO</priority>
<name>implicit destructor generated for class 'Name'</name>
<description>The named class does not itself have an explicit destructor but either had a base class that has a destructor or has a member class that has a destructor (or both). In this case a destructor will be generated by the compiler. [11, ?12.4]</description>
</rule>
<rule>
<key>1908</key>
<configkey>1908</configkey>
<priority>INFO</priority>
<name>'virtual' assumed for destructor'~Name()' (inherited from base class 'Name()</name>
<description>The destructor cited was inherited from a base class with a virtual destructor. This word 'virtual' was omitted from the declaration. It is common practice to omit this keyword when implied. A warning is issued (1512) when a base class's destructor is not virtual. See also 1909.</description>
</rule>
<rule>
<key>1909</key>
<configkey>1909</configkey>
<priority>INFO</priority>
<name>'virtual' assumed, see: function 'Symbol' (Location)</name>
<description>The named function overrides a base class virtual function and so is virtual. It is common practice to omit the virtual keyword in these cases although some feel that this leads to sloppy programming. This message allows programmers to detect and make explicit which functions are actually virtual.</description>
</rule>
<rule>
<key>1911</key>
<configkey>1911</configkey>
<priority>INFO</priority>
<name>Implicit call of constructor 'Symbol' (see text)</name>
<description>The Symbol in the message is the name of a constructor called to make an implicit conversion. This message can be helpful in tracking down hidden sources of inefficiencies. [11, ?12.1]</description>
</rule>
<rule>
<key>1912</key>
<configkey>1912</configkey>
<priority>INFO</priority>
<name>Implicit call of conversion function from class 'Name' to type 'Type'</name>
<description>A conversion function (one of the form Symbol::operator Type ()) was implicitly called. This message can be helpful in tracking down hidden sources of inefficiencies.</description>
</rule>
<rule>
<key>1914</key>
<configkey>1914</configkey>
<priority>INFO</priority>
<name>Default constructor 'Symbol' (Location) not referenced</name>
<description>A default constructor was not referenced. When a member function of a class is not referenced, you will normally receive an Informational message (1714) to that effect. When the member function is the default constructor, however, we give this Elective Note instead.
The rationale for this different treatment lay in the fact that many authors recommend defining a default constructor as a general principle. Indeed we give an Informational message (1712) when a default constructor is not defined for a class. Therefore, if you are following a modus operandi of not always defining a default constructor you may want to turn off message 1712 and turn on message 1914 instead.</description>
</rule>
<rule>
<key>1916</key>
<configkey>1916</configkey>
<priority>INFO</priority>
<name>Ellipsis encountered</name>
<description>An ellipsis was encountered while processing the prototype of some function declaration. An ellipsis is a way of breaking the typing system of C or C++.</description>
</rule>
<rule>
<key>1917</key>
<configkey>1917</configkey>
<priority>INFO</priority>
<name>Empty prototype for String, assumed '(void)'</name>
<description>This message is given when an empty prototype is detected either for a function definition or for a namespace declaration (the String specifies which). Whereas we give an Informational Message (1717) when a (non-member) declaration contains no prototype, we give a much milder Elective Note when a definition does the same. For example:
int f(); // Info 1717 int f() { return 1; } // Elective Note 1917
The reason for this is that the declaration form has a different meaning in C and C++. In C it is an incomplete declaration saying nothing about arguments. In C++ the declaration says there are no arguments. The definition, however, means the same in both languages. See also message 1918. [11, ?8.2.5]</description>
</rule>
<rule>
<key>1918</key>
<configkey>1918</configkey>
<priority>INFO</priority>
<name>empty prototype for member declaration, assumed (void)</name>
<description>A function declaration within a class contains an empty prototype. This case is similar to Info 1717 which complains about an empty prototype outside a class. It receives a lighter classification (Elective Note) because an empty prototype within a class cannot be ambiguous because C does not allow functions within classes. [11, ?8.2.5]</description>
</rule>
<rule>
<key>1919</key>
<configkey>1919</configkey>
<priority>INFO</priority>
<name>Multiple assignment operators for class 'Symbol'</name>
<description>For a given class more than one function was declared whose name was 'operator ='. This is not necessarily a bad thing. For example, a String class may very well have an assignment from char * and such an assignment may be advisable from an efficiency standpoint. However, it represents a loss of elegance because there will almost certainly be a char * constructor and an assignment operator which will represent another way of achieving the same effect.</description>
</rule>
<rule>
<key>1920</key>
<configkey>1920</configkey>
<priority>INFO</priority>
<name>Casting to a reference</name>
<description>The ARM[11] (Section 5.4) states that reference casts are often 'misguided'. However, too many programs are openly using reference casts to place such casts in the Informational category. [11, ?5.4]</description>
</rule>
<rule>
<key>1921</key>
<configkey>1921</configkey>
<priority>INFO</priority>
<name>Symbol 'Symbol' not checking argument against sizeof(class)</name>
<description>This note is given for either operator new or operator delete when defined as member functions. As member functions they are called when new (or delete) is applied to a class type or any derived class type. The difficulty is with the derived class type. Any specialized allocator is likely to be useless for a derived class type and hence experts suggest that a test be made of the size_t argument against sizeof(class). Specifically PC-lint/FlexeLint is looking for one of:
if( arg == sizeof(class) ) if( arg != sizeof(class) ) if( sizeof(class) == arg ) if( sizeof(class) != arg )
or the equivalent. If any such function is found that is a member of a class that is the base of a derivation, then in addition to Note 1921, we issue Warning 1531. (see Steve Simpson, "More on Memory Management", Dr. Dobb's Journal, August 1994, p. 10).</description>
</rule>
<rule>
<key>1922</key>
<configkey>1922</configkey>
<priority>INFO</priority>
<name>Symbol 'Symbol' not checking argument for NULL</name>
<description>This message is given for a function operator delete which is not checking its parameter for being the NULL pointer. We would normally expect to see some such check as:
if( arg ) if( arg == 0 ) if( arg != NULL )
etc. Classes which have destructors will normally filter out passing the NULL pointer into the operator delete so that this message is only in the Elective Note category. If there is no destructor you obtain a warning. See Warning 1532.</description>
</rule>
<rule>
<key>1923</key>
<configkey>1923</configkey>
<priority>INFO</priority>
<name>macro 'Symbol' could become const variable</name>
<description>The designated macro could probably be replaced by a const variable. A const variable is preferred in some quarters where, for example, a local debugger may not understand macros but would understand variables. [12, Item 1].
The message is issued for macros containing at least one constant or constant equivalent (an earlier const-able macro or const variable) and no other variables or tokens such as ';' of a non-expression nature.</description>
</rule>
<rule>
<key>1924</key>
<configkey>1924</configkey>
<priority>INFO</priority>
<name>C-style cast</name>
<description>A C-style cast was detected. This can be replaced by one of the newer C++ casts having the form: Name<Type>(Expression) where Name is one of static_cast, dynamic_cast, const_cast or reinterpret_cast. [23, Item 2].</description>
</rule>
<rule>
<key>1925</key>
<configkey>1925</configkey>
<priority>INFO</priority>
<name>Symbol 'Symbol' is a public data member</name>
<description>The indicated Symbol is a public data member of a class. If the class is introduced with the keyword struct the message is not issued. In some quarters the use of public data members is deprecated. The rationale is that if function calls replace data references in the public interface, the implementation can change without affecting the interface. [12, Item 20]</description>
</rule>
<rule>
<key>1926</key>
<configkey>1926</configkey>
<priority>INFO</priority>
<name>Symbol 'Symbol's default constructor implicitly called</name>
<description>A member of a class (identified by Symbol) did not appear in the constructor initialization list. Since it had a default constructor this constructor was implicitly called. Is this what the user intended? Some authorities suggest that all members should appear in the constructor initialization list. [12, Item 12].</description>
</rule>
<rule>
<key>1927</key>
<configkey>1927</configkey>
<priority>INFO</priority>
<name>Symbol 'Symbol' did not appear in the constructor initializer list</name>
<description>A member of a class (identified by Symbol) did not appear in a constructor initialization list. If the item remains uninitialized through the whole of the constructor, a Warning 1401 is issued. Some authorities suggest that all members should appear in the constructor initialization list. [12, Item 12].</description>
</rule>
<rule>
<key>1928</key>
<configkey>1928</configkey>
<priority>INFO</priority>
<name>Symbol 'Name' did not appear in the constructor initializer list</name>
<description>A base class (identified by Symbol) did not appear in a constructor initialization list. If a constructor does not appear, then the default constructor is called. This may or may not be valid behavior. If a base class is missing from a copy constructor's initializer list, then a more severe Warning (1538) is issued. [12, Item 12].</description>
</rule>
<rule>
<key>1929</key>
<configkey>1929</configkey>
<priority>INFO</priority>
<name>function 'Symbol' returning a reference</name>
<description>A non-member function was found to be returning a reference. This is not normally considered good practice because responsibility for deleting the object is not easily assigned. [12, Item 23].</description>
</rule>
<rule>
<key>1930</key>
<configkey>1930</configkey>
<priority>INFO</priority>
<name>Conversion operator 'Symbol' found</name>
<description>A conversion operator is a member function of the form: operator Type ();
This will be called implicitly by the compiler whenever an object (of the class type) is to be converted to type Type. Some programmers consider such implicit calls to be potentially harmful leading to programming situations that are difficult to diagnose. See for example [23, Item 5].</description>
</rule>
<rule>
<key>1931</key>
<configkey>1931</configkey>
<priority>INFO</priority>
<name>Constructor 'Symbol' can be used for implicit conversions</name>
<description>A constructor was found that could be used for implicit conversions. For example: class X { public: X(int); ... };
Here, any int (or type convertible to int) could be automatically converted to X. This can sometimes cause confusing behavior [23, Item 5]. If this is not what was intended, use the keyword 'explicit' as in: explicit X(int);
This will also serve to suppress this message.</description>
</rule>
<rule>
<key>1932</key>
<configkey>1932</configkey>
<priority>INFO</priority>
<name>Base class 'Symbol' is not abstract.</name>
<description>An abstract class is a class with at least one pure virtual specifier. At least one author has argued [23, Item 33] that all base classes should be abstract although this suggestion flies in the face of existing practice.</description>
</rule>
<rule>
<key>1933</key>
<configkey>1933</configkey>
<priority>INFO</priority>
<name>Call to unqualified virtual function 'Symbol' from non-static member function</name>
<description>A classical C++ gotcha is the calling of a virtual function from within a constructor or a destructor. When we discover a direct call from a constructor or destructor to a virtual function we issue Warning 1506. But what about indirect calls. Suppose a constructor calls a function that in turn, perhaps through several levels of call, calls a virtual function. This could be difficult to detect. Dan Saks [24] has suggested a compromise Guideline that "imposes few, if any, practical restrictions". The Guideline, implemented by this Elective Note, issues a message whenever an unqualified virtual function is called by any other (non-static) member function (for the same 'this' object). For example: class X { virtual void f(); void g(); };
void X::g() { f(); // Note 1933 X::f(); // ok -- non virtual call. }
Even if total abstinence is unwarranted, turning on message 1933 occasionally can be helpful in detecting situations when constructors or destructors call virtual functions.</description>
</rule>
<rule>
<key>1934</key>
<configkey>1934</configkey>
<priority>INFO</priority>
<name>Shift operator 'Symbol' should be non-member function</name>
<description>It has been suggested [12, Item 19] that you should never make a shift operator a member function unless you're defining ostream or istream (the message is suppressed in these two cases). The reason is that there is a temptation on the part of the novice to, for example, define output to ostream as a class member function left shift that takes ostream as an argument. This is exactly backwards. The shift operator normally employs the destination (or source) on the left.
On the other hand, if the class you are defining is the source or destination then defining the shift operators is entirely appropriate.</description>
</rule>
<rule>
<key>1935</key>
<configkey>1935</configkey>
<priority>INFO</priority>
<name>Dynamic initialization for class object 'Symbol1' (references 'Symbol2')</name>
<description>A static class-like object whose name is Symbol1 is dynamically initialized by referencing Symbol2 (the latter is normally a constructor for the former). The reason for noting this initialization is that the order of inter-module dynamic initializations is not defined. (Within a module, however, the intializations are done in the order of appearance.) Hence, if the constructor is itself dependent on dynamic initialization occurring in another module the behavior is undefined. For example: class X { X(): ... };
X x:
This will elicit Elective Note 1935 that x is being initialized dynamically by a call to X::X(). Now, if this constructor were to be accessing information that depended on the order of evaluation (such as accessing the value of x itself) the result would be undefined. We have no evidence of this at this point. and for this reason the message is in the Elective Note category. However, programmers with a suspected order-of-initialization problem will probably want to turn this on. See also 1936, 1937, 1544 and 1545.</description>
</rule>
<rule>
<key>1936</key>
<configkey>1936</configkey>
<priority>INFO</priority>
<name>Dynamic initialization for scalar 'Symbol1' (references 'Symbol2')</name>
<description>A static scalar whose name is Symbol1 is dynamically initialized and references Symbol2 during the initialization. For example, let a module consist only of: int f(); int n = f();
Here we report that n is dynamically initialized by f(). There may be other symbols referenced, Symbol2 is just the first. The reason for noting this initialization is that the order of inter-module dynamic initializations is not defined. (Within a module, however, the initializations are done in the order of appearance.) If Symbol2 were a variable, then PC-lint/FlexeLint could determine that the variable is dynamically initialized in another module and issue a 1544 or 1545 as appropriate. However, the symbol referenced could be a function (as in the example) and PC-lint/FlexeLint does not analyze the complete function call graph to determine whether there is a dependency on another dynamic initialization. See also 1935 and 1937.</description>
</rule>
<rule>
<key>1937</key>
<configkey>1937</configkey>
<priority>INFO</priority>
<name>Static variable 'Symbol' has a destructor.</name>
<description>A static scalar whose name is Symbol has a destructor. Destructors of static objects are invoked in a predictable order only for objects within the same module (the reverse order of construction). For objects in different modules this order is indeterminate. Hence, if the correct operation of a destructor depends on the existence of an object in some other module an indeterminacy could result. See also 1935, 1936, 1544 and 1545.</description>
</rule>
<rule>
<key>1938</key>
<configkey>1938</configkey>
<priority>INFO</priority>
<name>constructor 'Symbol' accesses global data.</name>
<description>A constructor is accessing global data. It is generally not a good idea for constructors to access global data because order of initialization dependencies can be created. If the global data is itself initialized in another module and if the constructor is accessed during initialization, a 'race' condition is established. [12, Item 47]</description>
</rule>
<rule>
<key>1939</key>
<configkey>1939</configkey>
<priority>INFO</priority>
<name>Down cast detected</name>
<description>A down cast is a cast from a pointer (or reference) to a base class to a pointer (or reference) to a derived class. A cast down the class hierarchy is fraught with danger. Are you sure that the alleged base class pointer really points to an object in the derived class. Some amount of down casting is necessary but a wise programmer will reduce this to a minimum. [12, Item 39]</description>
</rule>
<rule>
<key>1940</key>
<configkey>1940</configkey>
<priority>INFO</priority>
<name>Address of reference parameter 'Symbol' transferred outside of function</name>
<description>The address of a reference parameter is being transferred (either via a return statement, assigned to a static, or assigned through a pointer parameter) to a point where it can persist beyond the lifetime of the function. These are all violations of the Linton Convention (see Murray [21]).
The particular instance at hand is with a reference to a non-const and as such is not considered as dangerous as with a reference to a const. (See 1780, 1781 and 1782 in Section 13.8 Informational Messages for those cases). For example: int *f( int &n ) { return &n; } int g(); int *p = f( g() ); would create a problem were it not for the fact that this is diagnosed as a non-lvalue being assigned to a reference to non-const.</description>
</rule>
<rule>
<key>1941</key>
<configkey>1941</configkey>
<priority>INFO</priority>
<name>Assignment operator for class 'Symbol' does not return a const reference to class</name>
<description>The typical use of an assignment operator for class C is to assign new information to variables of class C. If this were the entire story there would be no need for the assignment operator to return anything. However, it is conventional to support chains of assignment as in: C x, y, z; ... x = y = z; // parsed as x = (y = z); For this reason assignment normally returns a reference to the object assigned the value. For example, assignment (y = z) would return a reference to y.
Since it is almost never the case that this variable is to be reassigned, i.e. we almost never wish to write: (x = y) = z; // unusual as a general rule it is better to make the assignment operator return a const reference. This will generate a warning when the unusual case is attempted.
But experts differ. Some maintain that in order to support non-const member functions operating directly on the result of an assignment as in: (x = y).mangle(); where, as its name suggests, mangle is non-const it would be necessary for the return value of assignment to be non-const. Another reason to not insist on the const qualifier is that the default assignment operator returns simply a reference to object and not a reference to const object. In an age of generic programming, compatibility may more important than the additional protection that the const would offer.</description>
</rule>
<rule>
<key>1942</key>
<configkey>1942</configkey>
<priority>INFO</priority>
<name>Unqualified name 'Symbol' subject to misinterpretation owing to dependent base class</name>
<description>An unqualified name used within a class template was not found within the class and, moreover, the class has at least one dependent base class. There is a potential ambiguity here. According to the standard, the dependent base class should not be searched either at template definition time or at template instantiation time. Nonetheless, some implementations do make that search at instantiation time. Even if the compiler is conforming, the implementator or even a reader of the code may think the base class is searched leading to confusion.
To eliminate the abiguity, the name should be fully qualified (or referenced using this). For example: class X; template< class T > class A : T { X *p; bool f() { return y; } }; Both the reference to X (on line 5) and to y (one line 6) will be flagged. One possible modification is: class X; template< class T > class A : T { ::X *p; bool f() { return this->y; } }; This solidifies and disambiguates the code. The reference to X is guaranteed to be the X on line 1 and can no longer be high-jacked by the base class. Also, since y is not a member of A, the class will not instantiate unless y is found to be a member of the base class.</description>
</rule>
<rule>
<key>1960</key>
<configkey>1960</configkey>
<priority>INFO</priority>
<name>Violates MISRA C++ Required Rule Name, String</name>
<description>In addition to a C coding standard, MISRA has also compiled a C++ one. We suggest use of the options file au-misra-cpp.lnt to activate these and other MISRA C++ messages.
The list of checks made are as follows:
(Rule 0-1-8) Void return type for function without external side-effects. (Rule 2-13-2) Octal constant or escape sequence used. (Rule 2-13-4) Lower case literal suffix. (Rule 3-1-1) Object/function definitions in headers. (Rule 3-1-2) Function not declared at file scope. (Rule 5-0-3) Implicit conversion of cvalue. (Rule 5-0-4) Implicit conversion changes signedness. (Rule 5-0-5) Implicit conversion between integer and floating point types. (Rule 5-0-6) Implicit conversion to smaller type. (Rule 5-0-7) Cast of cvalue between integer and floating point types. (Rule 5-0-8) Cast of cvalue to larger type. (Rule 5-0-9) Cast of cvalue changes signedness. (Rule 5-0-10) Recasting required for operators '~' and '<<'. (rule 5-0-19) More than two pointer indirection levels used. (Rule 5-0-21) Bitwise operator applied to signed underlying type . (Rule 5-2-12) Array-pointer decay when passing the array to a function . (Rule 5-3-2) Prohibited operator applied to unsigned underlying type: . (Rule 5-3-3) Overloading unary &. (Rule 5-3-4) 'sizeof' used on expressions with side effect. (Rule 5-14-1) Side effects on right hand side of logical operator. (Rule 5-18-1) Comma operator used. (Rule 6-2-3) Null statement not in line by itself. (Rules 6-3-1 and 6-4-1) Left brace expected for if, else, for, do, switch and while. (Rule 6-4-2) No 'else' at end of 'if ... else if' chain. (Rule 6-4-7) Boolean value in switch expression. (Rule 6-6-2) Gotos jumping to an earlier point in the code. (Rule 6-6-3) continue statement should not be used. (Rule 6-6-4) More than one 'break' terminates loop. (Rule 7-3-1) Global declarations other than main(), namespace declarations, extern "C" declarations and arithmetic typedefs. (Rule 7-3-2) Using the identifier main for functions other than the global one. (Rule 7-3-3) Unnamed namespaces in headers. (Rule 7-3-4) No using-directives allowed. (Rule 7-3-6) using-directives or using declarations (except class and/or block scope using declarations) in header files. (Rule 8-0-1) Multiple declarators in a declaration. (Rule 8-4-1) Function has variable number of arguments. (Rule 8-5-3) Should initialize either all enum members or only the first. (Rule 9-5-1) Unions shall not be used. (Rule 14-8-1) Explicit specialization of overloaded function templates. (Rule 15-1-3) Empty throw outside of a catch block. (Rule 15-3-7) Catch handler after catch(...) in a try-catch sequence. (Rule 16-0-1) Only preprocessor statements and comments before '#include'. (Rule 16-0-2) '#define/#undef' used within a block. (Rule 16-0-3) Use of '#undef' is discouraged. (Rule 16-0-4) Use of function-like macros is discouraged. (Rule 16-1-1) Non-standard use of 'defined' preprocessor operator. (Rule 16-2-4) Header file name with non-standard character: . (Rule 16-3-1) Multiple use of '#' and/or '##' operators in macro definition.
You may disable individual rules to your taste by using the Rule number in an esym option; see Message 960.</description>
</rule>
<rule>
<key>1961</key>
<configkey>1961</configkey>
<priority>INFO</priority>
<name>virtual member function 'Symbol' could be made const</name>
<description>This message is similar to message 1762 (member function could be made const) except that it is issued for a virtual function. You may not want to make virtual functions const because then any overriding function would have to be const as well. Consider, for example: class A { virtual void f() {} /* ... */ }; class B : public A { int a; void f() { a = 0; } };
Here, class B overrides A's function f() and, in doing so, modifies member a. If A::f() had been declared const, this would not have been possible.
Nonetheless, a particularly rigorous user may want to hunt down such virtual functions and make them all const and so this Note is provided.
This message is also similar to Note 1962 which is issued for functions that make deep modifications. Note 1962 takes priority over 1961. That is, a virtual function that makes a deep modification (but no shallow modifications) will have Note 1962 issued but not Note 1961.</description>
</rule>
<rule>
<key>1962</key>
<configkey>1962</configkey>
<priority>INFO</priority>
<name>Non-const member function 'Symbol' contains a deep modification.</name>
<description>The designated member function could be declared const but shouldn't be because it contains a deep modification. For example: class X { char *p; public: void f() { *p = 0; } x(); };
will elicit this message indicating that X::f() contains a deep modification. A modification is considered shallow if it modifies (or exposes for modification) a class member directly. A modification is considered deep if it modifies information indirectly through a class member pointer. This Elective Note is available for completeness so that a programmer can find all functions that could result in a class being modified. It does not indicate that the programming is deficient. In particular, if the function is marked const an Info 1763 will be issued. See also 1762, 1763.</description>
</rule>
<rule>
<key>1963</key>
<configkey>1963</configkey>
<priority>INFO</priority>
<name>Violates MISRA C++ Advisory Rule Name, String</name>
<description>This message is issued for some violations of the MISRA C++ advisory guidelines. We suggest use of the options file au-misra-cpp.lnt to activate these and other MISRA C++ messages.
The list of checks made are as follows: (Rule 2-5-1) Possible digraph used. (Rule 5-0-2) Dependence placed on C's operator precedence. (Rule 14-8-2) Mixing template and non-template functions in a viable sets. (Rule 15-0-2) Throwing a pointer expression. (Rule 16-2-5) Header file name with non-standard character. (Rule 16-3-2) No use of '#' or '##'.</description>
</rule>
<!--MISRA C (2004) Rules-->
<rule>
<key>M1.1</key>
<configkey>M1.1</configkey>
<priority>INFO</priority>
<name>Strict ANSI checking, MISRA Rule 1.1</name>
<description>
Strict ANSI checking, MISRA Rule 1.1</description>
</rule>
<rule>
<key>M1.2</key>
<configkey>M1.2</configkey>
<priority>INFO</priority>
<name>No undefined or unspecified behavior, MISRA Rule 1.2 </name>
<description>
No undefined or unspecified behavior, MISRA Rule 1.2</description>
</rule>
<rule>
<key>M1.4</key>
<configkey>M1.4</configkey>
<priority>INFO</priority>
<name>Identifier names must be unique in first 31 characters, MISRA Rule 1.4</name>
<description>
Identifier names must be unique in first 31 characters, MISRA Rule 1.4: </description>
</rule>
<rule>
<key>M2.1</key>
<configkey>M2.1</configkey>
<priority>INFO</priority>
<name>No in-line assembly language, MISRA Rule 2.1</name>
<description>
No in-line assembly language, MISRA Rule 2.1</description>
</rule>
<rule>
<key>M2.2</key>
<configkey>M2.2</configkey>
<priority>INFO</priority>
<name>Do not use // comments, MISRA Rule 2.2</name>
<description>
Do not use // comments, MISRA Rule 2.2</description>
</rule>
<rule>
<key>M2.3</key>
<configkey>M2.3</configkey>
<priority>INFO</priority>
<name>No nested comments, MISRA Rule 2.3</name>
<description>
No nested comments</description>
</rule>
<rule>
<key>M2.4</key>
<configkey>M2.4</configkey>
<priority>INFO</priority>
<name>No nested comments, MISRA advisory Rule 2.4</name>
<description>
No nested comments</description>
</rule>
<rule>
<key>M3.4</key>
<configkey>M3.4</configkey>
<priority>INFO</priority>
<name>Report on pragma use, MISRA Rule 3.4</name>
<description>
Report on pragma use</description>
</rule>
<rule>
<key>M3.6</key>
<configkey>M3.6</configkey>
<priority>INFO</priority>
<name>libraries should conform to MISRA standard, MISRA Rule 3.6</name>
<description>
libraries should conform to MISRA standard</description>
</rule>
<rule>
<key>M4.1</key>
<configkey>M4.1</configkey>
<priority>INFO</priority>
<name>do not use non-ANSI escape sequences, MISRA Rule 4.1</name>
<description>
do not use non-ANSI escape sequences</description>
</rule>
<rule>
<key>M4.2</key>
<configkey>M4.2</configkey>
<priority>INFO</priority>
<name>do not use trigraphs, MISRA Rule 4.2</name>
<description>
do not use trigraphs</description>
</rule>
<rule>
<key>M5.1</key>
<configkey>M5.1</configkey>
<priority>INFO</priority>
<name>identifier names must be unique in first 31 characters, MISRA Rule 5.1</name>
<description>
identifier names must be unique in first 31 characters</description>
</rule>
<rule>
<key>M5.2</key>
<configkey>M5.2</configkey>
<priority>INFO</priority>
<name>complain about name hiding, MISRA Rule 5.2</name>
<description>
complain about name hiding</description>
</rule>
<rule>
<key>M5.3</key>
<configkey>M5.3</configkey>
<priority>INFO</priority>
<name>Do not reuse typedef names, MISRA Rule 5.3</name>
<description>
Do not reuse typedef names</description>
</rule>
<rule>
<key>M5.4</key>
<configkey>M5.4</configkey>
<priority>INFO</priority>
<name>Do not reuse tag names, MISRA Rule 5.4</name>
<description>
Do not reuse tag names</description>
</rule>
<rule>
<key>M5.5</key>
<configkey>M5.5</configkey>
<priority>INFO</priority>
<name>Complain about name hiding, MISRA advisory Rule 5.5</name>
<description>
Complain about name hiding</description>
</rule>
<rule>
<key>M5.6</key>
<configkey>M5.6</configkey>
<priority>INFO</priority>
<name>Complain about name hiding, MISRA advisory Rule 5.6</name>
<description>
Complain about name hiding</description>
</rule>
<rule>
<key>M5.7</key>
<configkey>M5.7</configkey>
<priority>INFO</priority>
<name>Do not reuse identifier names, MISRA advisory Rule 5.7</name>
<description>
Do not reuse identifier names</description>
</rule>
<rule>
<key>M6.1</key>
<configkey>M6.1</configkey>
<priority>INFO</priority>
<name>disallowed use of plain char, MISRA Rule 6.1</name>
<description>
disallowed use of plain char</description>
</rule>
<rule>
<key>M6.2</key>
<configkey>M6.2</configkey>
<priority>INFO</priority>
<name>disallowed use of plain char, MISRA Rule 6.2</name>
<description>
disallowed use of plain char</description>
</rule>
<rule>
<key>M6.3</key>
<configkey>M6.3</configkey>
<priority>INFO</priority>
<name>do not use modifiers (int, char, etc) outside of a typedef, MISRA advisory rule 6.3</name>
<description>
do not use modifiers (int, char, etc) outside of a typedef</description>
</rule>
<rule>
<key>M6.4</key>
<configkey>M6.4</configkey>
<priority>INFO</priority>
<name>bitfield type should be unsigned int or signed int, MISRA rule 6.4</name>
<description>
bitfield type should be unsigned int or signed int</description>
</rule>
<rule>
<key>M6.5</key>
<configkey>M6.5</configkey>
<priority>INFO</priority>
<name>small bit field should be unsigned int, MISRA rule 6.5</name>
<description>
small bit field should be unsigned int</description>
</rule>
<rule>
<key>M7.1</key>
<configkey>M7.1</configkey>
<priority>INFO</priority>
<name>Octal constant used, MISRA Rule 7.1</name>
<description>
Octal constant used. </description>
</rule>
<rule>
<key>M8.1</key>
<configkey>M8.1</configkey>
<priority>INFO</priority>
<name>use function prototypes, MISRA Rule 8.1 </name>
<description>
use function prototypes </description>
</rule>
<rule>
<key>M8.2</key>
<configkey>M8.2</configkey>
<priority>INFO</priority>
<name>function has no explicit type, MISRA Rule 8.2 </name>
<description>
function has no explicit type</description>
</rule>
<rule>
<key>M8.3</key>
<configkey>M8.3</configkey>
<priority>INFO</priority>
<name>declaration and definition should have identical parameter types, MISRA Rule 8.3</name>
<description>
declaration and definition should have identical parameter types</description>
</rule>
<rule>
<key>M8.4</key>
<configkey>M8.4</configkey>
<priority>INFO</priority>
<name>symbol redeclared, MISRA Rule 8.4</name>
<description>
symbol redeclared</description>
</rule>
<rule>
<key>M8.5</key>
<configkey>M8.5</configkey>
<priority>INFO</priority>
<name>No definitions of objects or function in header files, MISRA Rule 8.5</name>
<description>
No definitions of objects or function in header files.</description>
</rule>
<rule>
<key>M8.6</key>
<configkey>M8.6</configkey>
<priority>INFO</priority>
<name>Function not declared at file scope, MISRA Rule 8.6</name>
<description>
Function not declared at file scope.</description>
</rule>
<rule>
<key>M8.7</key>
<configkey>M8.7</configkey>
<priority>INFO</priority>
<name>could define variable at block scope, MISRA Rule 8.7</name>
<description>
could define variable at block scope</description>
</rule>
<rule>
<key>M8.8</key>
<configkey>M8.8</configkey>
<priority>INFO</priority>
<name>object/function previously declared, MISRA Rule 8.8</name>
<description>
object/function previously declared</description>
</rule>
<rule>
<key>M8.9</key>
<configkey>M8.9</configkey>
<priority>INFO</priority>
<name>symbol previously defined, MISRA Rule 8.9</name>
<description>
symbol previously defined</description>
</rule>
<rule>
<key>M8.10</key>
<configkey>M8.10</configkey>
<priority>INFO</priority>
<name>symbol could be made static, MISRA Rule 8.10</name>
<description>
symbol could be made static</description>
</rule>
<rule>
<key>M8.11</key>
<configkey>M8.11</configkey>
<priority>INFO</priority>
<name>symbol previously used as static, MISRA Rule 8.11</name>
<description>
symbol previously used as static</description>
</rule>
<rule>
<key>M8.12</key>
<configkey>M8.12</configkey>
<priority>INFO</priority>
<name>array has 0 dimension, MISRA Rule 8.12</name>
<description>
array has 0 dimension</description>
</rule>
<rule>
<key>M9.1</key>
<configkey>M9.1</configkey>
<priority>INFO</priority>
<name>symbol not initialized, MISRA Rule 9.1</name>
<description>
symbol not initialized</description>
</rule>
<rule>
<key>M9.2</key>
<configkey>M9.2</configkey>
<priority>INFO</priority>
<name>omitted braces within an initializer, MISRA Rule 9.2</name>
<description>
omitted braces within an initializer</description>
</rule>
<rule>
<key>M9.3</key>
<configkey>M9.3</configkey>
<priority>INFO</priority>
<name>Should initialize either all enum members or only the first, MISRA Rule 9.3</name>
<description>
Should initialize either all enum members or only the first.</description>
</rule>
<rule>
<key>M10.1</key>
<configkey>M10.1</configkey>
<priority>INFO</priority>
<name>loss of precision / possible loss of fraction, MISRA Rule 10.1</name>
<description>
The value of an expression of integer type shall not be implicitly converted to a different underlying type if:
a) it is not a conversion to a wider integer type of the same signedness, or
b) the expression is complex, or
c) the expression is not constant and is a function argument, or
d) the expression is not constant and is a return expression</description>
</rule>
<rule>
<key>M10.2</key>
<configkey>M10.2</configkey>
<priority>INFO</priority>
<name>prototype coercion, MISRA Rule 10.2</name>
<description>
prototype coercion</description>
</rule>
<rule>
<key>M10.3</key>
<configkey>M10.3</configkey>
<priority>INFO</priority>
<name>prohibited cast of complex integer expression, MISRA Rule 10.3</name>
<description>
prohibited cast of complex integer expression</description>
</rule>
<rule>
<key>M10.4</key>
<configkey>M10.4</configkey>
<priority>INFO</priority>
<name>prohibited cast of complex floating point, MISRA Rule 10.4</name>
<description>
prohibited cast of complex floating point</description>
</rule>
<rule>
<key>M10.5</key>
<configkey>M10.5</configkey>
<priority>INFO</priority>
<name>recasting required for << and - operators, MISRA Rule 10.5</name>
<description>
recasting required for << and - operators</description>
</rule>
<rule>
<key>M10.6</key>
<configkey>M10.6</configkey>
<priority>INFO</priority>
<name>unsigned integer literals require a „U‟ suffix, MISRA Rule 10.6</name>
<description>
unsigned integer literals require a „U‟ suffix</description>
</rule>
<rule>
<key>M11.1</key>
<configkey>M11.1</configkey>
<priority>INFO</priority>
<name>cast pointer to non-pointer, MISRA Rule 11.1</name>
<description>
cast pointer to non-pointer</description>
</rule>
<rule>
<key>M11.2</key>
<configkey>M11.2</configkey>
<priority>INFO</priority>
<name>cast pointer to non-pointer, MISRA Rule 11.2</name>
<description>
cast pointer to non-pointer</description>
</rule>
<rule>
<key>M11.3</key>
<configkey>M11.3</configkey>
<priority>INFO</priority>
<name>cast pointer to non-pointer, MISRA advisory Rule 11.3</name>
<description>
cast pointer to non-pointer</description>
</rule>
<rule>
<key>M11.4</key>
<configkey>M11.4</configkey>
<priority>INFO</priority>
<name>cast pointer to pointer, MISRA advisory Rule 11.4</name>
<description>
cast pointer to pointer</description>
</rule>
<rule>
<key>M11.5</key>
<configkey>M11.5</configkey>
<priority>INFO</priority>
<name>attempt to cast away const/volatile from a pointer or reference, MISRA Rule 11.5</name>
<description>
attempt to cast away const/volatile from a pointer or reference</description>
</rule>
<rule>
<key>M12.1</key>
<configkey>M12.1</configkey>
<priority>INFO</priority>
<name>dependence on C's operator precedence, MISRA advisory Rule 12.1</name>
<description>
dependence on C's operator precedence</description>
</rule>
<rule>
<key>M12.2</key>
<configkey>M12.2</configkey>
<priority>INFO</priority>
<name>order of evaluation, MISRA advisory Rule 12.2</name>
<description>
order of evaluation</description>
</rule>
<rule>
<key>M12.3</key>
<configkey>M12.3</configkey>
<priority>INFO</priority>
<name>'sizeof' used on expressions with side effect, MISRA Rule 12.3</name>
<description>
'sizeof' used on expressions with side effect</description>
</rule>
<rule>
<key>M12.4</key>
<configkey>M12.4</configkey>
<priority>INFO</priority>
<name>Side effects on right hand side of logical operator, MISRA Rule 12.4</name>
<description>
Side effects on right hand side of logical operator.</description>
</rule>
<rule>
<key>M12.5</key>
<configkey>M12.5</configkey>
<priority>INFO</priority>
<name>non-primary expression used with logical operator, MISRA Rule 12.5</name>
<description>
non-primary expression used with logical operator</description>
</rule>
<rule>
<key>M12.6</key>
<configkey>M12.6</configkey>
<priority>INFO</priority>
<name>boolean expression required for logical operator, MISRA advisory Rule 12.6</name>
<description>
boolean expression required for logical operator</description>
</rule>
<rule>
<key>M12.7</key>
<configkey>M12.7</configkey>
<priority>INFO</priority>
<name>Bitwise operator applied to signed underlying type, MISRA Rule 12.7</name>
<description>
Bitwise operator applied to signed underlying type.</description>
</rule>
<rule>
<key>M12.8</key>
<configkey>M12.8</configkey>
<priority>INFO</priority>
<name>excessive shift value, MISRA Rule 12.8</name>
<description>
excessive shift value</description>
</rule>
<rule>
<key>M12.9</key>
<configkey>M12.9</configkey>
<priority>INFO</priority>
<name>Prohibited operator applied to unsigned underlying type, MISRA Rule 12.9</name>
<description>
Prohibited operator applied to unsigned underlying type.</description>
</rule>
<rule>
<key>M12.10</key>
<configkey>M12.10</configkey>
<priority>INFO</priority>
<name>Comma operator used outside of 'for' expression, MISRA Rule 12.10</name>
<description>
Comma operator used outside of 'for' expression.</description>
</rule>
<rule>
<key>M12.11</key>
<configkey>M12.11</configkey>
<priority>INFO</priority>
<name>overflow in computing constant, MISRA advisory Rule 12.11</name>
<description>
overflow in computing constant</description>
</rule>
<rule>
<key>M12.12</key>
<configkey>M12.12</configkey>
<priority>INFO</priority>
<name>bit representation of a floating point type used, MISRA Rule 12.12</name>
<description>
bit representation of a floating point type used</description>
</rule>
<rule>
<key>M12.13</key>
<configkey>M12.13</configkey>
<priority>INFO</priority>
<name>increment or decrement combined with another operator, MISRA advisory Rule 12.13</name>
<description>
increment or decrement combined with another operator</description>
</rule>
<rule>
<key>M13.1</key>
<configkey>M13.1</configkey>
<priority>INFO</priority>
<name>boolean test of assignment, MISRA Rule 13.1</name>
<description>
boolean test of assignment</description>
</rule>
<rule>
<key>M13.2</key>
<configkey>M13.2</configkey>
<priority>INFO</priority>
<name>boolean test of assignment, MISRA advisory Rule 13.2</name>
<description>
boolean test of assignment</description>
</rule>
<rule>
<key>M13.3</key>
<configkey>M13.3</configkey>
<priority>INFO</priority>
<name>testing floats for equality, MISRA advisory Rule 13.3</name>
<description>
testing floats for equality, partialy covered</description>
</rule>
<rule>
<key>M13.4</key>
<configkey>M13.4</configkey>
<priority>INFO</priority>
<name>Floating point variable used as loop counter, MISRA Rule 13.4</name>
<description>
Floating point variable used as loop counter.</description>
</rule>
<rule>
<key>M13.5</key>
<configkey>M13.5</configkey>
<priority>INFO</priority>
<name>„for‟ loop expressions do not match, MISRA Rule 13.5</name>
<description>
„for‟ loop expressions do not match</description>
</rule>
<rule>
<key>M13.6</key>
<configkey>M13.6</configkey>
<priority>INFO</priority>
<name>detect loop variables modified within the loop, MISRA Rule 13.6</name>
<description>
detect loop variables modified within the loop</description>
</rule>
<rule>
<key>M13.7</key>
<configkey>M13.7</configkey>
<priority>INFO</priority>
<name>constant value Boolean, MISRA Rule 13.7</name>
<description>
constant value Boolean</description>
</rule>
<rule>
<key>M14.1</key>
<configkey>M14.1</configkey>
<priority>INFO</priority>
<name>unreachable code, MISRA Rule 14.1</name>
<description>
unreachable code</description>
</rule>
<rule>
<key>M14.2</key>
<configkey>M14.2</configkey>
<priority>INFO</priority>
<name>non-null statement has no effect, MISRA Rule 14.2</name>
<description>
non-null statement has no effect</description>
</rule>
<rule>
<key>M14.3</key>
<configkey>M14.3</configkey>
<priority>INFO</priority>
<name>Null statement not in line by itself, MISRA Rule 14.3</name>
<description>
Null statement not in line by itself.</description>
</rule>
<rule>
<key>M14.4</key>
<configkey>M14.4</configkey>
<priority>INFO</priority>
<name>do not use goto, MISRA Rule 14.4</name>
<description>
do not use goto</description>
</rule>
<rule>
<key>M14.5</key>
<configkey>M14.5</configkey>
<priority>INFO</priority>
<name>continue statement should not be used, MISRA Rule 14.5</name>
<description>
continue statement should not be used.</description>
</rule>
<rule>
<key>M14.6</key>
<configkey>M14.6</configkey>
<priority>INFO</priority>
<name>More than one 'break' terminates loop, MISRA Rule 14.6</name>
<description>
More than one 'break' terminates loop.</description>
</rule>
<rule>
<key>M14.7</key>
<configkey>M14.7</configkey>
<priority>INFO</priority>
<name>return before function end, MISRA Rule 14.7</name>
<description>
return before function end</description>
</rule>
<rule>
<key>M14.8</key>
<configkey>M14.8</configkey>
<priority>INFO</priority>
<name>use braces around body of switch, else, for, do, while, MISRA Rule 14.8</name>
<description>
use braces around body of switch, else, for, do, while</description>
</rule>
<rule>
<key>M14.9</key>
<configkey>M14.9</configkey>
<priority>INFO</priority>
<name>use braces around body of if, else, else if, MISRA Rule 14.9</name>
<description>
use braces around body of if, else, else if</description>
</rule>
<rule>
<key>M14.10</key>
<configkey>M14.10</configkey>
<priority>INFO</priority>
<name>No 'else' at end of 'if ... else if' chain, MISRA Rule 14.10</name>
<description>
No 'else' at end of 'if ... else if' chain.</description>
</rule>
<rule>
<key>M15.0</key>
<configkey>M15.0</configkey>
<priority>INFO</priority>
<name>use MISRA switch syntax, MISRA Rule 15.0</name>
<description>
use MISRA switch syntax</description>
</rule>
<rule>
<key>M15.1</key>
<configkey>M15.1</configkey>
<priority>INFO</priority>
<name>need a switch, MISRA Rule 15.1</name>
<description>
need a switch</description>
</rule>
<rule>
<key>M15.2</key>
<configkey>M15.2</configkey>
<priority>INFO</priority>
<name>use break to terminate case, MISRA Rule 15.2</name>
<description>
use break to terminate case</description>
</rule>
<rule>
<key>M15.3</key>
<configkey>M15.3</configkey>
<priority>INFO</priority>
<name>case label follows default in switch statement, MISRA Rule 15.3</name>
<description>
case label follows default in switch statement</description>
</rule>
<rule>
<key>M15.4</key>
<configkey>M15.4</configkey>
<priority>INFO</priority>
<name>Boolean value in switch expression, MISRA Rule 15.4</name>
<description>
Boolean value in switch expression</description>
</rule>
<rule>
<key>M15.5</key>
<configkey>M15.5</configkey>
<priority>INFO</priority>
<name>switch does not have a case, MISRA Rule 15.5</name>
<description>
switch does not have a case</description>
</rule>
<rule>
<key>M16.1</key>
<configkey>M16.1</configkey>
<priority>INFO</priority>
<name>Function has variable number of arguments, MISRA Rule 16.1</name>
<description>
Function has variable number of arguments.</description>
</rule>
<rule>
<key>M16.2</key>
<configkey>M16.2</configkey>
<priority>INFO</priority>
<name>do not use recursive functions, MISRA Rule 16.2</name>
<description>
do not use recursive functions</description>
</rule>
<rule>
<key>M16.3</key>
<configkey>M16.3</configkey>
<priority>INFO</priority>
<name>use identifiers for all parameters in a prototype, MISRA Rule 16.3</name>
<description>
use identifiers for all parameters in a prototype</description>
</rule>
<rule>
<key>M16.4</key>
<configkey>M16.4</configkey>
<priority>INFO</priority>
<name>function parameter list differs from prior declaration, MISRA Rule 16.4</name>
<description>
function parameter list differs from prior declaration</description>
</rule>
<rule>
<key>M16.5</key>
<configkey>M16.5</configkey>
<priority>INFO</priority>
<name>function declaration is missing type info, MISRA Rule 16.5</name>
<description>
function declaration is missing type info</description>
</rule>
<rule>
<key>M16.6</key>
<configkey>M16.6</configkey>
<priority>INFO</priority>
<name>too few or too many arguments for prototype, MISRA Rule 16.6</name>
<description>
too few or too many arguments for prototype</description>
</rule>
<rule>
<key>M16.7</key>
<configkey>M16.7</configkey>
<priority>INFO</priority>
<name>use const on paramaters where appropriate, MISRA advisory Rule 16.7</name>
<description>
use const on paramaters where appropriate</description>
</rule>
<rule>
<key>M16.8</key>
<configkey>M16.8</configkey>
<priority>INFO</priority>
<name>function should return a value, MISRA Rule 16.8</name>
<description>
function should return a value</description>
</rule>
<rule>
<key>M16.9</key>
<configkey>M16.9</configkey>
<priority>INFO</priority>
<name>function identifier used without „&‟ or parenthesized parameter list, MISRA Rule 16.9</name>
<description>
function identifier used without „&‟ or parenthesized parameter list</description>
</rule>
<rule>
<key>M16.10</key>
<configkey>M16.10</configkey>
<priority>INFO</priority>
<name>ignoring return value of function, MISRA Rule 16.10</name>
<description>
ignoring return value of function</description>
</rule>
<rule>
<key>M17.1</key>
<configkey>M17.1</configkey>
<priority>INFO</priority>
<name>pointer arithmetic used on non-array, MISRA Rule 17.1</name>
<description>
pointer arithmetic used on non-array</description>
</rule>
<rule>
<key>M17.2</key>
<configkey>M17.2</configkey>
<priority>INFO</priority>
<name>relational or subtract operator applied to pointers, MISRA Rule 17.2</name>
<description>
relational or subtract operator applied to pointers</description>
</rule>
<rule>
<key>M17.3</key>
<configkey>M17.3</configkey>
<priority>INFO</priority>
<name>relational or subtract operator applied to pointers, MISRA Rule 17.3</name>
<description>
relational or subtract operator applied to pointers</description>
</rule>
<rule>
<key>M17.4</key>
<configkey>M17.4</configkey>
<priority>INFO</priority>
<name>pointer arithmetic by increment or decrement, MISRA Rule 17.4</name>
<description>
pointer arithmetic by increment or decrement</description>
</rule>
<rule>
<key>M17.5</key>
<configkey>M17.5</configkey>
<priority>INFO</priority>
<name>more than two pointer indirection levels used, MISRA advisory Rule 17.5</name>
<description>
more than two pointer indirection levels used</description>
</rule>
<rule>
<key>M17.6</key>
<configkey>M17.6</configkey>
<priority>INFO</priority>
<name>assigning address of auto to outer scope symbol or to static, MISRA Rule 17.6</name>
<description>
assigning address of auto to outer scope symbol or to static</description>
</rule>
<rule>
<key>M18.1</key>
<configkey>M18.1</configkey>
<priority>INFO</priority>
<name>vacuous type for variable, MISRA Rule 18.1</name>
<description>
vacuous type for variable</description>
</rule>
<rule>
<key>M18.4</key>
<configkey>M18.4</configkey>
<priority>INFO</priority>
<name>Unions shall not be used,MISRA Rule 18.4</name>
<description>
Unions shall not be used.</description>
</rule>
<rule>
<key>M19.1</key>
<configkey>M19.1</configkey>
<priority>INFO</priority>
<name>only preprocessor statements and comments before '#include', MISRA Advisory Rule 19.1</name>
<description>
only preprocessor statements and comments before '#include'</description>
</rule>
<rule>
<key>M19.2</key>
<configkey>M19.2</configkey>
<priority>INFO</priority>
<name>header file name with non-standard character, MISRA Advisory Rule 19.2</name>
<description>
header file name with non-standard character</description>
</rule>
<rule>
<key>M19.3</key>
<configkey>M19.3</configkey>
<priority>INFO</priority>
<name>need < or " after #include, MISRA Rule 19.3</name>
<description>
need < or " after #include</description>
</rule>
<rule>
<key>M19.4</key>
<configkey>M19.4</configkey>
<priority>INFO</priority>
<name>expression-like macro not parenthesized, MISRA Rule 19.4</name>
<description>
expression-like macro not parenthesized</description>
</rule>
<rule>
<key>M19.5</key>
<configkey>M19.5</configkey>
<priority>INFO</priority>
<name>'#define/#undef' used within a block, MISRA Rule 19.5</name>
<description>
'#define/#undef' used within a block.</description>
</rule>
<rule>
<key>M19.6</key>
<configkey>M19.6</configkey>
<priority>INFO</priority>
<name>Use of '#undef' prohibited, MISRA Rule 19.6</name>
<description>
Use of '#undef' prohibited</description>
</rule>
<rule>
<key>M19.7</key>
<configkey>M19.7</configkey>
<priority>INFO</priority>
<name>use function instead of function-like macro, MISRA advisory Rule 19.7</name>
<description>
use function instead of function-like macro</description>
</rule>
<rule>
<key>M19.8</key>
<configkey>M19.8</configkey>
<priority>INFO</priority>
<name>syntax error in call of macro, MISRA Rule 19.8</name>
<description>
syntax error in call of macro</description>
</rule>
<rule>
<key>M19.9</key>
<configkey>M19.9</configkey>
<priority>INFO</priority>
<name>preprocessor directives in macro invocation, MISRA Rule 19.9</name>
<description>
preprocessor directives in macro invocation</description>
</rule>
<rule>
<key>M19.10</key>
<configkey>19.10</configkey>
<priority>INFO</priority>
<name>expression-like macro not parenthesized, MISRA Rule 19.10</name>
<description>
expression-like macro not parenthesized</description>
</rule>
<rule>
<key>M19.11</key>
<configkey>M19.11</configkey>
<priority>INFO</priority>
<name>undefined preprocessor variable, MISRA Rule 19.11</name>
<description>
undefined preprocessor variable</description>
</rule>
<rule>
<key>M19.12</key>
<configkey>M19.12</configkey>
<priority>INFO</priority>
<name>Multiple use of '#' and/or '##' operators in macro definition, MISRA Rule 19.12</name>
<description>
Multiple use of '#' and/or '##' operators in macro definition.</description>
</rule>
<rule>
<key>M19.13</key>
<configkey>M19.13</configkey>
<priority>INFO</priority>
<name>do not use of # or ## operators in macro definition, MISRA advisory Rule 19.13</name>
<description>
do not use of # or ## operators in macro definition</description>
</rule>
<rule>
<key>M19.14</key>
<configkey>M19.14</configkey>
<priority>INFO</priority>
<name>Non-standard use of 'defined' preprocessor operator, MISRA Rule 19.14</name>
<description>
Non-standard use of 'defined' preprocessor operator.</description>
</rule>
<rule>
<key>M19.15</key>
<configkey>M19.15</configkey>
<priority>INFO</priority>
<name>repeated include file, MISRA Rule 19.15</name>
<description>
repeated include file</description>
</rule>
<rule>
<key>M19.16</key>
<configkey>M19.16</configkey>
<priority>INFO</priority>
<name>#endif or #else is not followed by EOL, MISRA Rule 19.16</name>
<description>
#endif or #else is not followed by EOL</description>
</rule>
<rule>
<key>M19.17</key>
<configkey>M19.17</configkey>
<priority>INFO</priority>
<name>#if not closed within file, MISRA Rule 19.17</name>
<description>
#if not closed within file</description>
</rule>
<rule>
<key>M20.1</key>
<configkey>M20.1</configkey>
<priority>INFO</priority>
<name>do not redefine standard functions, MISRA Rule 20.1</name>
<description>
do not redefine standard functions</description>
</rule>
<rule>
<key>M20.2</key>
<configkey>M20.2</configkey>
<priority>INFO</priority>
<name>re-use of reserved identifier, MISRA Rule 20.2</name>
<description>
re-use of reserved identifier</description>
</rule>
<rule>
<key>M20.3</key>
<configkey>M20.3</configkey>
<priority>INFO</priority>
<name>calls to standard library functions are checked, MISRA Rule 20.3</name>
<description>
calls to standard library functions are checked</description>
</rule>
<rule>
<key>M20.4</key>
<configkey>M20.4</configkey>
<priority>INFO</priority>
<name>do not use dynamic heap allocation, MISRA Rule 20.4</name>
<description>
do not use dynamic heap allocation</description>
</rule>
<rule>
<key>M20.5</key>
<configkey>M20.5</configkey>
<priority>INFO</priority>
<name>do not use errno, MISRA Rule 20.5</name>
<description>
do not use errno</description>
</rule>
<rule>
<key>M20.6</key>
<configkey>M20.6</configkey>
<priority>INFO</priority>
<name>do not use offsetof, MISRA Rule 20.6</name>
<description>
do not use offsetof</description>
</rule>
<rule>
<key>M20.7</key>
<configkey>M20.7</configkey>
<priority>INFO</priority>
<name>do not use longjmp, setjmp, MISRA Rule 20.7</name>
<description>
do not use longjmp, setjmp</description>
</rule>
<rule>
<key>M20.8</key>
<configkey>M20.8</configkey>
<priority>INFO</priority>
<name>do not use signal, raise, MISRA Rule 20.8</name>
<description>
do not use signal, raise</description>
</rule>
<rule>
<key>M20.9</key>
<configkey>M20.9</configkey>
<priority>INFO</priority>
<name>do not use stdio.h, MISRA Rule 20.9</name>
<description>
do not use stdio.h</description>
</rule>
<rule>
<key>M20.10</key>
<configkey>M20.10</configkey>
<priority>INFO</priority>
<name>do not use atof, atio, atoll, MISRA Rule 20.10</name>
<description>
do not use atof, atio, atoll</description>
</rule>
<rule>
<key>M20.11</key>
<configkey>M20.11</configkey>
<priority>INFO</priority>
<name>do not use abort, exit, getenv, system, MISRA Rule 20.11</name>
<description>
do not use abort, exit, getenv, system</description>
</rule>
<rule>
<key>M20.12</key>
<configkey>M20.12</configkey>
<priority>INFO</priority>
<name>do not use time, strftime, clock, difftime, mktime, MISRA Rule 20.12</name>
<description>
do not use time, strftime, clock, difftime, mktime</description>
</rule>
<rule>
<key>M21.1</key>
<configkey>M21.1</configkey>
<priority>INFO</priority>
<name>static analysis by using PC-lint/FlexeLint, MISRA Rule 21.1</name>
<description>
static analysis by using PC-lint/FlexeLint</description>
</rule>
<!--MISRA C++ (2008) Rules-->
<rule>
<key>M0-1-1</key>
<configkey>M0-1-1</configkey>
<priority>INFO</priority>
<name>Unrechable, MISRA C++ Rule 0-1-1</name>
<description>Unrechable</description>
</rule>
<rule>
<key>M0-1-2</key>
<configkey>M0-1-2</configkey>
<priority>INFO</priority>
<name>infeasible path, MISRA C++ Rule 0-1-2</name>
<description>infeasible path</description>
</rule>
<rule>
<key>M0-1-3</key>
<configkey>M0-1-3</configkey>
<priority>INFO</priority>
<name>unused variable, MISRA C++ Rule 0-1-3</name>
<description>unused variable</description>
</rule>
<rule>
<key>M0-1-4</key>
<configkey>M0-1-4</configkey>
<priority>INFO</priority>
<name>symbol not referenced or accessed, MISRA C++ Rule 0-1-4</name>
<description>symbol not referenced or accessed</description>
</rule>
<rule>
<key>M0-1-5</key>
<configkey>M0-1-5</configkey>
<priority>INFO</priority>
<name>unused type declaration, MISRA C++ Rule 0-1-5</name>
<description>unused type declaration</description>
</rule>
<rule>
<key>M0-1-6</key>
<configkey>M0-1-6</configkey>
<priority>INFO</priority>
<name>last value assigned to variable not used, MISRA C++ Rule 0-1-6</name>
<description>last value assigned to variable not used</description>
</rule>
<rule>
<key>M0-1-7</key>
<configkey>M0-1-7</configkey>
<priority>INFO</priority>
<name>ignoring return value of function, MISRA C++ Rule 0-1-7</name>
<description>ignoring return value of function</description>
</rule>
<rule>
<key>M0-1-8</key>
<configkey>M0-1-8</configkey>
<priority>INFO</priority>
<name>Void return type for function without external side-effects, MISRA C++ Rule 0-1-8</name>
<description>Void return type for function without external side-effects.</description>
</rule>
<rule>
<key>M0-1-9</key>
<configkey>M0-1-9</configkey>
<priority>INFO</priority>
<name>dead(redundant) code, MISRA C++ Rule 0-1-9</name>
<description>dead(redundant) code</description>
</rule>
<rule>
<key>M0-1-10</key>
<configkey>M0-1-10</configkey>
<priority>INFO</priority>
<name>unused function, MISRA C++ Rule 0-1-10</name>
<description>unused function</description>
</rule>
<rule>
<key>M0-1-11</key>
<configkey>M0-1-11</configkey>
<priority>INFO</priority>
<name>unused function parameter, MISRA C++ Rule 0-1-11</name>
<description>unused function parameter</description>
</rule>
<rule>
<key>M0-1-12</key>
<configkey>M0-1-12</configkey>
<priority>INFO</priority>
<name>unused function parameter, MISRA C++ Rule 0-1-12</name>
<description>unused function parameter</description>
</rule>
<rule>
<key>M0-2-1</key>
<configkey>M0-2-1</configkey>
<priority>INFO</priority>
<name>unions shall not be used, MISRA C++ Rule 0-2-1</name>
<description>unions shall not be used</description>
</rule>
<!--
MISRA C++ Rule 0-3-1 automatically accomplished by using PC-lint/FlexeLint
-->
<rule>
<key>M0-3-2</key>
<configkey>M0-3-2</configkey>
<priority>INFO</priority>
<name>ignoring return value of function, MISRA C++ Rule 0-3-2</name>
<description>ignoring return value of function</description>
</rule>
<!--
MISRA C++ rule 0-4-1 doc, not statically checkable
MISRA C++ rule 0-4-2 doc, not statically checkable
MISRA C++ rule 0-4-3 doc, not statically checkable
MISRA C++ rule 0-4-4 doc, not statically checkable
-->
<rule>
<key>M1-0-1</key>
<configkey>M1-0-1</configkey>
<priority>INFO</priority>
<name>strict ANSI / ISO, MISRA C++ Rule 1-0-1</name>
<description>strict ANSI / ISO</description>
</rule>
<!--
MISRA C++ rule 1-0-2 req, not statically checkable
MISRA C++ rule 1-0-3 doc, not statically checkable
MISRA C++ rule 2-2-1 doc, not statically checkable
-->
<rule>
<key>M2-3-1</key>
<configkey>M2-3-1</configkey>
<priority>INFO</priority>
<name>do not use trigraphs, MISRA C++ Rule 2-3-1</name>
<description>do not use trigraphs</description>
</rule>
<rule>
<key>M2-3-1</key>
<configkey>M2-3-1</configkey>
<priority>INFO</priority>
<name>do not use trigraphs, MISRA C++ Rule 2-3-1</name>
<description>do not use trigraphs</description>
</rule>
<rule>
<key>M2-5-1</key>
<configkey>M2-5-1</configkey>
<priority>INFO</priority>
<name>possible digraph used, MISRA C++ Advisory Rule 2-5-1</name>
<description>possible digraph used</description>
</rule>
<rule>
<key>M2-7-1</key>
<configkey>M2-7-1</configkey>
<priority>INFO</priority>
<name>do not nest comments, MISRA C++ Rule 2-7-1</name>
<description>do not nest comments</description>
</rule>
<!--
MISRA C++ rule 2-7-2 req n/a not statically checkable
MISRA C++ rule 2-7-3 adv n/a not statically checkable
-->
<rule>
<key>M2-10-1</key>
<configkey>M2-10-1</configkey>
<priority>INFO</priority>
<name>suspicious constant, MISRA C++ Rule 2-10-1</name>
<description>suspicious constant. Partialy covered</description>
</rule>
<rule>
<key>M2-10-2</key>
<configkey>M2-10-2</configkey>
<priority>INFO</priority>
<name>report on name hiding, MISRA C++ Rule 2-10-2</name>
<description>report on name hiding</description>
</rule>
<!--
MISRA C++ rule 2-10-3 req no not currently supported
MISRA C++ rule 2-10-4 req no not currently supported
MISRA C++ rule 2-10-5 adv no not currently supported
-->
<rule>
<key>M2-10-6</key>
<configkey>M2-10-6</configkey>
<priority>INFO</priority>
<name>symbol redeclared, MISRA C++ Rule 2-10-6</name>
<description>symbol redeclared</description>
</rule>
<rule>
<key>M2-13-1</key>
<configkey>M2-13-1</configkey>
<priority>INFO</priority>
<name>non-ANSI escape sequence, MISRA C++ Rule 2-13-1</name>
<description>non-ANSI escape sequence</description>
</rule>
<rule>
<key>M2-13-2</key>
<configkey>M2-13-2</configkey>
<priority>INFO</priority>
<name>octal constant or escape sequence used, MISRA C++ Rule 2-13-2</name>
<description>octal constant or escape sequence used</description>
</rule>
<rule>
<key>M2-13-3</key>
<configkey>M2-13-3</configkey>
<priority>INFO</priority>
<name>unsigned octal & hexadecimal literals require a ‘U’ suffix, MISRA C++ Rule 2-13-3</name>
<description>unsigned octal & hexadecimal literals require a ‘U’ suffix</description>
</rule>
<rule>
<key>M2-13-4</key>
<configkey>M2-13-4</configkey>
<priority>INFO</priority>
<name>Lower case literal suffix, MISRA C++ Rule 2-13-4</name>
<description>Lower case literal suffix.</description>
</rule>
<rule>
<key>M2-13-5</key>
<configkey>M2-13-5</configkey>
<priority>INFO</priority>
<name>mixing narrow and wide string literals in concatenation, MISRA C++ Rule 2-13-5</name>
<description>mixing narrow and wide string literals in concatenation</description>
</rule>
<rule>
<key>M3-1-1</key>
<configkey>M3-1-1</configkey>
<priority>INFO</priority>
<name>Object/function definitions in headers, MISRA C++ Rule 3-1-1</name>
<description>Object/function definitions in headers.</description>
</rule>
<rule>
<key>M3-1-2</key>
<configkey>M3-1-2</configkey>
<priority>INFO</priority>
<name>Function not declared at file scope, MISRA C++ Rule 3-1-2</name>
<description>Function not declared at file scope.</description>
</rule>
<rule>
<key>M3-1-3</key>
<configkey>M3-1-3</configkey>
<priority>INFO</priority>
<name>Array has dimension 0, MISRA C++ Rule 3-1-3</name>
<description>Array has dimension 0.</description>
</rule>
<rule>
<key>M3-2-1</key>
<configkey>M3-2-1</configkey>
<priority>INFO</priority>
<name>Symbol is redeclared or redefined, MISRA C++ Rule 3-2-1</name>
<description>Symbol is redeclared or redefined.</description>
</rule>
<rule>
<key>M3-2-2</key>
<configkey>M3-2-2</configkey>
<priority>INFO</priority>
<name>Symbol is redeclared or redefined, MISRA C++ Rule 3-2-2</name>
<description>symbol is redeclared or redefined.</description>
</rule>
<rule>
<key>M3-2-3</key>
<configkey>M3-2-3</configkey>
<priority>INFO</priority>
<name>Object/function type previously declared, MISRA C++ Rule 3-2-3</name>
<description>Object/function type previously declared.</description>
</rule>
<rule>
<key>M3-2-4</key>
<configkey>M3-2-4</configkey>
<priority>INFO</priority>
<name>Symbol is redeclared or redefined, MISRA C++ Rule 3-2-4</name>
<description>Symbol is redeclared or redefined.</description>
</rule>
<rule>
<key>M3-3-1</key>
<configkey>M3-3-1</configkey>
<priority>INFO</priority>
<name>Header declaration for symbol could be moved from header tomodule
/ symbol could be made static, MISRA C++ Rule 3-3-1</name>
<description>Header declaration for symbol could be moved from header tomodule
/ symbol could be made static.</description>
</rule>
<rule>
<key>M3-3-2</key>
<configkey>M3-3-2</configkey>
<priority>INFO</priority>
<name>Static symbol not declared static, MISRA C++ Rule 3-3-2</name>
<description>Static symbol not declared static.</description>
</rule>
<!--
MISRA C++ rule 3-4-1 req no not currently supported
MISRA C++ rule 3-9-1 req no not currently supported
-->
<rule>
<key>M3-9-2</key>
<configkey>M3-9-2</configkey>
<priority>INFO</priority>
<name>Type or modifier used outside of typedef, MISRA C++ Advisory Rule 3-9-2</name>
<description>Type or modifier used outside of typedef.</description>
</rule>
<rule>
<key>M3-9-3</key>
<configkey>M3-9-3</configkey>
<priority>INFO</priority>
<name>Bit representation of a floating point type used, MISRA C++ Rule 3-9-3</name>
<description>Bit representation of a floating point type used.</description>
</rule>
<rule>
<key>M4-5-1</key>
<configkey>M4-5-1</configkey>
<priority>INFO</priority>
<name>Boolean expression used with non-permitted operator, MISRA C++ Rule 4-5-1</name>
<description>Boolean expression used with non-permitted operator.</description>
</rule>
<!--
MISRA C++ rule 4-5-2 req no not currently supported
-->
<rule>
<key>M4-5-3</key>
<configkey>M4-5-3</configkey>
<priority>INFO</priority>
<name>Plain char used with prohibited operator, MISRA C++ Rule 4-5-3</name>
<description>Plain char used with prohibited operator.</description>
</rule>
<!--
MISRA C++ rule 4-10-1 req no not currently supported
-->
<rule>
<key>M4-10-2</key>
<configkey>M4-10-2</configkey>
<priority>INFO</priority>
<name>Implicit conversion from 0 to pointer, MISRA C++ Rule 4-10-2</name>
<description>Implicit conversion from 0 to pointer.</description>
</rule>
<rule>
<key>M5-0-1</key>
<configkey>M5-0-1</configkey>
<priority>INFO</priority>
<name>Order of evaluation, MISRA C++ Rule 5-0-1</name>
<description>Order of evaluation.</description>
</rule>
<rule>
<key>M5-0-2</key>
<configkey>M5-0-2</configkey>
<priority>INFO</priority>
<name>Dependence placed on C’s operator precedence, MISRA C++ Advisory Rule 5-0-2</name>
<description>Dependence placed on C’s operator precedence.</description>
</rule>
<rule>
<key>M5-0-3</key>
<configkey>M5-0-3</configkey>
<priority>INFO</priority>
<name>Implicit conversion of cvalue, MISRA C++ Rule 5-0-3</name>
<description>Implicit conversion of cvalue.</description>
</rule>
<rule>
<key>M5-0-4</key>
<configkey>M5-0-4</configkey>
<priority>INFO</priority>
<name>Implicit conversion changes signedness, MISRA C++ Rule 5-0-4</name>
<description>Implicit conversion changes signedness.</description>
</rule>
<rule>
<key>M5-0-5</key>
<configkey>M5-0-5</configkey>
<priority>INFO</priority>
<name>Implicit conversion between integer and floating point types, MISRA C++ Rule 5-0-5</name>
<description>Implicit conversion between integer and floating point types.</description>
</rule>
<rule>
<key>M5-0-6</key>
<configkey>M5-0-6</configkey>
<priority>INFO</priority>
<name>Implicit conversion to smaller type, MISRA C++ Rule 5-0-6</name>
<description>Implicit conversion to smaller type.</description>
</rule>
<rule>
<key>M5-0-7</key>
<configkey>M5-0-7</configkey>
<priority>INFO</priority>
<name>Cast of cvalue between integer and floating point types, MISRA C++ Rule 5-0-7</name>
<description>Cast of cvalue between integer and floating point types.</description>
</rule>
<rule>
<key>M5-0-8</key>
<configkey>M5-0-8</configkey>
<priority>INFO</priority>
<name>Cast of cvalue to larger type, MISRA C++ Rule 5-0-8</name>
<description>Cast of cvalue to larger type.</description>
</rule>
<rule>
<key>M5-0-9</key>
<configkey>M5-0-9</configkey>
<priority>INFO</priority>
<name>Cast of cvalue changes signedness, MISRA C++ Rule 5-0-9</name>
<description>Cast of cvalue changes signedness.</description>
</rule>
<rule>
<key>M5-0-10</key>
<configkey>M5-0-10</configkey>
<priority>INFO</priority>
<name>Recasting required for operators '~' and '<<', MISRA C++ Rule 5-0-10</name>
<description>Recasting required for operators '~' and '<<'.</description>
</rule>
<rule>
<key>M5-0-11</key>
<configkey>M5-0-11</configkey>
<priority>INFO</priority>
<name>Type other than plain char, MISRA C++ Rule 5-0-11</name>
<description>Type other than plain char.</description>
</rule>
<rule>
<key>M5-0-12</key>
<configkey>M5-0-12</configkey>
<priority>INFO</priority>
<name>Disallowed use of non-numeric value, MISRA C++ Rule 5-0-12</name>
<description>Disallowed use of non-numeric value.</description>
</rule>
<rule>
<key>M5-0-13</key>
<configkey>M5-0-13</configkey>
<priority>INFO</priority>
<name>Implicit conversion, MISRA C++ Rule 5-0-13</name>
<description>Implicit conversion.</description>
</rule>
<rule>
<key>M5-0-14</key>
<configkey>M5-0-14</configkey>
<priority>INFO</priority>
<name>Implicit conversion, MISRA C++ Rule 5-0-14</name>
<description>Implicit conversion.</description>
</rule>
<rule>
<key>M5-0-15</key>
<configkey>M5-0-15</configkey>
<priority>INFO</priority>
<name>pointer arithmetic other than array indexing used, MISRA C++ Rule 5-0-15</name>
<description>pointer arithmetic other than array indexing used.</description>
</rule>
<rule>
<key>M5-0-16</key>
<configkey>M5-0-16</configkey>
<priority>INFO</priority>
<name>Out-of-bounds pointer, MISRA C++ Rule 5-0-16</name>
<description>Out-of-bounds pointer.</description>
</rule>
<rule>
<key>M5-0-17</key>
<configkey>M5-0-17</configkey>
<priority>INFO</priority>
<name>Subtract operator applied to pointers, MISRA C++ Rule 5-0-17</name>
<description>Subtract operator applied to pointers.</description>
</rule>
<rule>
<key>M5-0-18</key>
<configkey>M5-0-18</configkey>
<priority>INFO</priority>
<name>Relational operator applied to pointers, MISRA C++ Rule 5-0-18</name>
<description>Relational operator applied to pointers.</description>
</rule>
<rule>
<key>M5-0-19</key>
<configkey>M5-0-19</configkey>
<priority>INFO</priority>
<name>More than two pointer indirection levels used, MISRA C++ Rule 5-0-19</name>
<description>More than two pointer indirection levels used.</description>
</rule>
<!--
MISRA C++ rule 5-0-20 req no not currently supported
-->
<rule>
<key>M5-0-21</key>
<configkey>M5-0-21</configkey>
<priority>INFO</priority>
<name>Bitwise operator applied to signed underlying type, MISRA C++ Rule 5-0-21</name>
<description>Bitwise operator applied to signed underlying type .</description>
</rule>
<rule>
<key>M5-2-1</key>
<configkey>M5-2-1</configkey>
<priority>INFO</priority>
<name>non-postfix expression used with logical operator, MISRA C++ Rule 5-2-1</name>
<description>non-postfix expression used with logical operator.</description>
</rule>
<rule>
<key>M5-2-2</key>
<configkey>M5-2-2</configkey>
<priority>INFO</priority>
<name>use dynamic_cast to downcast polymorphic type, MISRA C++ Rule 5-2-2</name>
<description>use dynamic_cast to downcast polymorphic type.</description>
</rule>
<!--
MISRA C++ rule 5-2-3 adv no not currently supported
-->
<rule>
<key>M5-2-4</key>
<configkey>M5-2-4</configkey>
<priority>INFO</priority>
<name>C-style cast, MISRA C++ Rule 5-2-4</name>
<description>C-style cast.</description>
</rule>
<rule>
<key>M5-2-5</key>
<configkey>M5-2-5</configkey>
<priority>INFO</priority>
<name>attempt to cast away const/volatile from a pointer or reference, MISRA C++ Rule 5-2-5</name>
<description>attempt to cast away const/volatile from a pointer or reference.</description>
</rule>
<rule>
<key>M5-2-6</key>
<configkey>M5-2-6</configkey>
<priority>INFO</priority>
<name>Suspicious cast / unusual pointer cast, MISRA C++ Rule 5-2-6</name>
<description>Suspicious cast / unusual pointer cast.</description>
</rule>
<rule>
<key>M5-2-7</key>
<configkey>M5-2-7</configkey>
<priority>INFO</priority>
<name>Pointer conversion to an unrelated type, MISRA C++ Rule 5-2-7</name>
<description>Pointer conversion to an unrelated type.</description>
</rule>
<rule>
<key>M5-2-8</key>
<configkey>M5-2-8</configkey>
<priority>INFO</priority>
<name>Cast from integer or pointer to void to a pointer to an object, MISRA C++ Advisory Rule 5-2-8</name>
<description>Cast from integer or pointer to void to a pointer to an object.</description>
</rule>
<rule>
<key>M5-2-9</key>
<configkey>M5-2-9</configkey>
<priority>INFO</priority>
<name>Cast from pointer to integral type, MISRA C++ Advisory Rule 5-2-9</name>
<description>Cast from pointer to integral type.</description>
</rule>
<rule>
<key>M5-2-10</key>
<configkey>M5-2-10</configkey>
<priority>INFO</priority>
<name>Increment or decrement combined with another operator, MISRA C++ Advisory Rule 5-2-10</name>
<description>Increment or decrement combined with another operator.</description>
</rule>
<rule>
<key>M5-2-11</key>
<configkey>M5-2-11</configkey>
<priority>INFO</priority>
<name>overloading special operators – comma && ||, MISRA C++ Rule 5-2-11</name>
<description>overloading special operators – comma && ||.</description>
</rule>
<rule>
<key>M5-2-12</key>
<configkey>M5-2-12</configkey>
<priority>INFO</priority>
<name>Array-pointer decay when passing the array to a function, MISRA C++ Rule 5-2-12</name>
<description>Array-pointer decay when passing the array to a function.</description>
</rule>
<rule>
<key>M5-3-1</key>
<configkey>M5-3-1</configkey>
<priority>INFO</priority>
<name>boolean expression required for operator: '||'; the -strong(B,...) option can help provide Boolean-by-enforcement, MISRA C++ Rule 5-3-1</name>
<description>boolean expression required for operator: '||'; the -strong(B,...) option can help provide Boolean-by-enforcement.</description>
</rule>
<rule>
<key>M5-3-2</key>
<configkey>M5-3-2</configkey>
<priority>INFO</priority>
<name>Prohibited operator applied to unsigned underlying type, MISRA C++ Rule 5-3-2</name>
<description>Prohibited operator applied to unsigned underlying type.</description>
</rule>
<rule>
<key>M5-3-3</key>
<configkey>M5-3-3</configkey>
<priority>INFO</priority>
<name>Overloading unary &, MISRA C++ Rule 5-3-3</name>
<description>Overloading unary &</description>
</rule>
<rule>
<key>M5-3-4</key>
<configkey>M5-3-4</configkey>
<priority>INFO</priority>
<name>'sizeof' used on expressions with side effect, MISRA C++ Rule 5-3-4</name>
<description>'sizeof' used on expressions with side effect.</description>
</rule>
<rule>
<key>M5-8-1</key>
<configkey>M5-8-1</configkey>
<priority>INFO</priority>
<name>excessive shift value, MISRA C++ Rule 5-8-1</name>
<description>excessive shift value</description>
</rule>
<rule>
<key>M5-14-1</key>
<configkey>M5-14-1</configkey>
<priority>INFO</priority>
<name>Side effects on right hand side of logical operator, MISRA C++ Rule 5-14-1</name>
<description>Side effects on right hand side of logical operator.</description>
</rule>
<!--
MISRA C++ rule 5-17-1 req no not currently supported
-->
<rule>
<key>M5-18-1</key>
<configkey>M5-18-1</configkey>
<priority>INFO</priority>
<name>Comma operator used, MISRA C++ Rule 5-18-1</name>
<description>Comma operator used.</description>
</rule>
<rule>
<key>M5-19-1</key>
<configkey>M5-19-1</configkey>
<priority>INFO</priority>
<name>Overflow in computing constant, MISRA C++ Advisory Rule 5-19-1</name>
<description>Overflow in computing constant.</description>
</rule>
<rule>
<key>M6-2-1</key>
<configkey>M6-2-1</configkey>
<priority>INFO</priority>
<name>Assignment operator used in sub-expression, MISRA C++ Rule 6-2-1</name>
<description>Assignment operator used in sub-expression.</description>
</rule>
<rule>
<key>M6-2-2</key>
<configkey>M6-2-2</configkey>
<priority>INFO</priority>
<name>Testing floats for equality, MISRA C++ Rule 6-2-2</name>
<description>Testing floats for equality.</description>
</rule>
<rule>
<key>M6-2-3</key>
<configkey>M6-2-3</configkey>
<priority>INFO</priority>
<name>Null statement not in line by itself, MISRA C++ Rule 6-2-3</name>
<description>Null statement not in line by itself.</description>
</rule>
<rule>
<key>M6-3-1</key>
<configkey>M6-3-1</configkey>
<priority>INFO</priority>
<name>Left brace expected for if, else, for, do, switch and while, MISRA C++ Rule 6-2-3</name>
<description>Left brace expected for if, else, for, do, switch and while.</description>
</rule>
<rule>
<key>M6-4-1</key>
<configkey>M6-4-1</configkey>
<priority>INFO</priority>
<name>Left brace expected for if, else, for, do, switch and while, MISRA C++ Rule 6-2-3</name>
<description>Left brace expected for if, else, for, do, switch and while.</description>
</rule>
<rule>
<key>M6-4-2</key>
<configkey>M6-4-2</configkey>
<priority>INFO</priority>
<name>No 'else' at end of 'if ... else if' chain, MISRA C++ Rule 6-4-2</name>
<description>No 'else' at end of 'if ... else if' chain.</description>
</rule>
<!--
MISRA C++ rule 6-4-3 req no not currently supported
MISRA C++ rule 6-4-4 req no not currently supported
-->
<rule>
<key>M6-4-5</key>
<configkey>M6-4-5</configkey>
<priority>INFO</priority>
<name>Control flows into case/default, MISRA C++ Rule 6-4-5</name>
<description>Control flows into case/default.</description>
</rule>
<rule>
<key>M6-4-6</key>
<configkey>M6-4-6</configkey>
<priority>INFO</priority>
<name>Switch statement has no default or case follows default, MISRA C++ Rule 6-4-6</name>
<description>Switch statement has no default or case follows default.</description>
</rule>
<rule>
<key>M6-4-7</key>
<configkey>M6-4-7</configkey>
<priority>INFO</priority>
<name>Boolean value in switch expression, MISRA C++ Rule 6-4-7</name>
<description>Boolean value in switch expression.</description>
</rule>
<rule>
<key>M6-4-8</key>
<configkey>M6-4-8</configkey>
<priority>INFO</priority>
<name>Switch does not have a case, MISRA C++ Rule 6-4-8</name>
<description>Switch does not have a case.</description>
</rule>
<!--
MISRA C++ rule 6-5-1 req no not currently supported
MISRA C++ rule 6-5-2 req no not currently supported
-->
<rule>
<key>M6-5-3</key>
<configkey>M6-5-3</configkey>
<priority>INFO</priority>
<name>Reuse of for loop variable could cause chaos, MISRA C++ Rule 6-5-3</name>
<description>Reuse of for loop variable could cause chaos.</description>
</rule>
<!--
MISRA C++ rule 6-5-4 req no not currently supported
MISRA C++ rule 6-5-5 req no not currently supported
MISRA C++ rule 6-5-6 req no not currently supported
MISRA C++ rule 6-6-1 req no not currently supported
-->
<rule>
<key>M6-6-2</key>
<configkey>M6-6-2</configkey>
<priority>INFO</priority>
<name>Gotos jumping to an earlier point in the code, MISRA C++ Rule 6-6-2</name>
<description>Gotos jumping to an earlier point in the code.</description>
</rule>
<rule>
<key>M6-6-3</key>
<configkey>M6-6-3</configkey>
<priority>INFO</priority>
<name>continue statement should not be used, MISRA C++ Rule 6-6-3</name>
<description>continue statement should not be used.</description>
</rule>
<rule>
<key>M6-6-4</key>
<configkey>M6-6-4</configkey>
<priority>INFO</priority>
<name>More than one 'break' terminates loop, MISRA C++ Rule 6-6-4</name>
<description>More than one 'break' terminates loop.</description>
</rule>
<rule>
<key>M6-6-5</key>
<configkey>M6-6-5</configkey>
<priority>INFO</priority>
<name>Return before function end, MISRA C++ Rule 6-6-5</name>
<description>Return before function end.</description>
</rule>
<rule>
<key>M7-1-1</key>
<configkey>M7-1-1</configkey>
<priority>INFO</priority>
<name>Use const on parameters where appropriate, MISRA C++ Rule 7-1-1</name>
<description>Use const on parameters where appropriate.</description>
</rule>
<rule>
<key>M7-1-2</key>
<configkey>M7-1-2</configkey>
<priority>INFO</priority>
<name>Use const on parameters where appropriate, MISRA C++ Rule 7-1-2</name>
<description>Use const on parameters where appropriate.</description>
</rule>
<!--
MISRA C++ rule 7-2-1 req Yes not currently supported
-->
<rule>
<key>M7-3-1</key>
<configkey>M7-3-1</configkey>
<priority>INFO</priority>
<name>Global declarations other than main(), namespace declarations, extern "C" declarations and arithmetic typedefs, MISRA C++ Rule 7-3-1</name>
<description>Global declarations other than main(), namespace declarations, extern "C" declarations and arithmetic typedefs.</description>
</rule>
<rule>
<key>M7-3-2</key>
<configkey>M7-3-2</configkey>
<priority>INFO</priority>
<name>Using the identifier main for functions other than the global one, MISRA C++ Rule 7-3-2</name>
<description>Using the identifier main for functions other than the global one.</description>
</rule>
<rule>
<key>M7-3-3</key>
<configkey>M7-3-3</configkey>
<priority>INFO</priority>
<name>Unnamed namespaces in headers, MISRA C++ Rule 7-3-3</name>
<description>Unnamed namespaces in headers.</description>
</rule>
<rule>
<key>M7-3-4</key>
<configkey>M7-3-4</configkey>
<priority>INFO</priority>
<name>No using-directives allowed, MISRA C++ Rule 7-3-4</name>
<description>No using-directives allowed.</description>
</rule>
<!--
MISRA C++ rule 7-3-5 req no not currently supported
-->
<rule>
<key>M7-3-6</key>
<configkey>M7-3-6</configkey>
<priority>INFO</priority>
<name>Using-directives or using declarations (except class and/or block scope using declarations) in header files, MISRA C++ Rule 7-3-6</name>
<description>Using-directives or using declarations (except class and/or block scope using declarations) in header files.</description>
</rule>
<!--
MISRA C++ rule 7-4-1 doc n/a not statically checkable
-->
<rule>
<key>M7-4-2</key>
<configkey>M7-4-2</configkey>
<priority>INFO</priority>
<name>Only use the asm declaration to introduce assembly code, MISRA C++ Rule 7-4-2</name>
<description>Only use the asm declaration to introduce assembly code.</description>
</rule>
<!--
MISRA C++ rule 7-4-3 req no not currently supported
-->
<rule>
<key>M7-5-1</key>
<configkey>M7-5-1</configkey>
<priority>INFO</priority>
<name>Returning address of auto variable, MISRA C++ Rule 7-5-1</name>
<description>Returning address of auto variable.</description>
</rule>
<rule>
<key>M7-5-2</key>
<configkey>M7-5-2</configkey>
<priority>INFO</priority>
<name>Assigning address of auto to static, MISRA C++ Rule 7-5-2</name>
<description>Assigning address of auto to static.</description>
</rule>
<rule>
<key>M7-5-3</key>
<configkey>M7-5-3</configkey>
<priority>INFO</priority>
<name>Returning address of reference to a const parameter address of reference parameter transferred outside of function, MISRA C++ Rule 7-5-3</name>
<description>Returning address of reference to a const parameter address of reference parameter transferred outside of function.</description>
</rule>
<rule>
<key>M7-5-4</key>
<configkey>M7-5-4</configkey>
<priority>INFO</priority>
<name>Worst case function for stack usage, MISRA C++ Rule 7-5-4</name>
<description>Worst case function for stack usage.</description>
</rule>
<rule>
<key>M8-0-1</key>
<configkey>M8-0-1</configkey>
<priority>INFO</priority>
<name>Multiple declarators in a declaration, MISRA C++ Rule 8-0-1</name>
<description>Multiple declarators in a declaration.</description>
</rule>
<rule>
<key>M8-3-1</key>
<configkey>M8-3-1</configkey>
<priority>INFO</priority>
<name>Virtual function has default parameter, MISRA C++ Rule 8-3-1</name>
<description>Virtual function has default parameter.</description>
</rule>
<rule>
<key>M8-4-1</key>
<configkey>M8-4-1</configkey>
<priority>INFO</priority>
<name>Function has variable number of arguments, MISRA C++ Rule 8-4-1</name>
<description>Function has variable number of arguments.</description>
</rule>
<rule>
<key>M8-4-2</key>
<configkey>M8-4-2</configkey>
<priority>INFO</priority>
<name>Function parameter list differs from prior declaration, MISRA C++ Rule 8-4-2</name>
<description>Function parameter list differs from prior declaration.</description>
</rule>
<rule>
<key>M8-4-3</key>
<configkey>M8-4-3</configkey>
<priority>INFO</priority>
<name>Function should return a value, MISRA C++ Rule 8-4-3</name>
<description>Function should return a value.</description>
</rule>
<rule>
<key>M8-4-4</key>
<configkey>M8-4-4</configkey>
<priority>INFO</priority>
<name>Function parameter list differs from prior declaration, MISRA C++ Rule 8-4-4</name>
<description>Function parameter list differs from prior declaration.</description>
</rule>
<rule>
<key>M8-5-1</key>
<configkey>M8-5-1</configkey>
<priority>INFO</priority>
<name>Symbol not initialized, MISRA C++ Rule 8-5-1</name>
<description>Symbol not initialized.</description>
</rule>
<rule>
<key>M8-5-2</key>
<configkey>M8-5-2</configkey>
<priority>INFO</priority>
<name>Omitted braces within an initializer, MISRA C++ Rule 8-5-2</name>
<description>Omitted braces within an initializer.</description>
</rule>
<rule>
<key>M8-5-3</key>
<configkey>M8-5-3</configkey>
<priority>INFO</priority>
<name>Should initialize either all enum members or only the first, MISRA C++ Rule 8-5-3</name>
<description>Should initialize either all enum members or only the first.</description>
</rule>
<rule>
<key>M9-3-1</key>
<configkey>M9-3-1</configkey>
<priority>INFO</priority>
<name>Const member function anomaly, MISRA C++ Rule 9-3-1</name>
<description>Const member function anomaly.</description>
</rule>
<rule>
<key>M9-3-2</key>
<configkey>M9-3-2</configkey>
<priority>INFO</priority>
<name>Member function returns non-const address, MISRA C++ Rule 9-3-2</name>
<description>Member function returns non-const address.</description>
</rule>
<rule>
<key>M9-3-3</key>
<configkey>M9-3-3</configkey>
<priority>INFO</priority>
<name>Member function could be made const, MISRA C++ Rule 9-3-3</name>
<description>Member function could be made const.</description>
</rule>
<rule>
<key>M9-5-1</key>
<configkey>M9-5-1</configkey>
<priority>INFO</priority>
<name>Unions shall not be used, MISRA C++ Rule 9-5-1</name>
<description>Unions shall not be used.</description>
</rule>
<!--
MISRA C++ rule 9-6-1 doc n/a not statically checkable
-->
<rule>
<key>M9-6-2</key>
<configkey>M9-6-2</configkey>
<priority>INFO</priority>
<name>Bit field type should be int, MISRA C++ Rule 9-6-2</name>
<description>Bit field type should be int.</description>
</rule>
<rule>
<key>M9-6-3</key>
<configkey>M9-6-3</configkey>
<priority>INFO</priority>
<name>Bit field type should be int, MISRA C++ Rule 9-6-3</name>
<description>Bit field type should be int.</description>
</rule>
<rule>
<key>M9-6-4</key>
<configkey>M9-6-4</configkey>
<priority>INFO</priority>
<name>Small bit field is signed rather than unsigned, MISRA C++ Rule 9-6-4</name>
<description>Small bit field is signed rather than unsigned.</description>
</rule>
<rule>
<key>M10-1-1</key>
<configkey>M10-1-1</configkey>
<priority>INFO</priority>
<name>Base class need not be virtual, MISRA C++ Advisory Rule 10-1-1</name>
<description>Base class need not be virtual.</description>
</rule>
<!--
MISRA C++ rule 10-1-2 req no not currently supported
-->
<rule>
<key>M10-1-3</key>
<configkey>M10-1-3</configkey>
<priority>INFO</priority>
<name>Non-virtual base class included twice in class, MISRA C++ Rule 10-1-3</name>
<description>Non-virtual base class included twice in class.</description>
</rule>
<!--
MISRA C++ rule 10-2-1 adv no not currently supported
MISRA C++ rule 10-3-1 req no not currently supported
-->
<rule>
<key>M10-3-2</key>
<configkey>M10-3-2</configkey>
<priority>INFO</priority>
<name>'virtual' assumed for function, MISRA C++ Rule 10-3-2</name>
<description>'virtual' assumed for function.</description>
</rule>
<!--
MISRA C++ rule 10-3-3 req no not currently supported
-->
<rule>
<key>M11-0-1</key>
<configkey>M11-0-1</configkey>
<priority>INFO</priority>
<name>Non-private data member within a non-POD structure, MISRA C++ Rule 11-0-1</name>
<description>Non-private data member within a non-POD structure.</description>
</rule>
<rule>
<key>M12-1-1</key>
<configkey>M12-1-1</configkey>
<priority>INFO</priority>
<name>Call to virtual function within a constructor or destructor, MISRA C++ Rule 12-1-1</name>
<description>Call to virtual function within a constructor or destructor.</description>
</rule>
<rule>
<key>M12-1-2</key>
<configkey>M12-1-2</configkey>
<priority>INFO</priority>
<name>Symbol did not appear in constructor initializer list, MISRA C++ Advisory Rule 12-1-2</name>
<description>Symbol did not appear in constructor initializer list.</description>
</rule>
<!--
MISRA C++ rule 12-1-3 req no not currently supported
-->
<rule>
<key>M12-8-1</key>
<configkey>M12-8-1</configkey>
<priority>INFO</priority>
<name>Constructor access global data, MISRA C++ Rule 12-8-1</name>
<description>Constructor access global data.</description>
</rule>
<rule>
<key>M12-8-2</key>
<configkey>M12-8-2</configkey>
<priority>INFO</priority>
<name>Public copy constructor in abstract class, MISRA C++ Rule 12-8-2</name>
<description>Public copy constructor in abstract class.</description>
</rule>
<rule>
<key>M14-5-1</key>
<configkey>M14-5-1</configkey>
<priority>INFO</priority>
<name>Generic function template associated with type, MISRA C++ Rule 14-5-1</name>
<description>Generic function template associated with type.</description>
</rule>
<rule>
<key>M14-5-2</key>
<configkey>M14-5-2</configkey>
<priority>INFO</priority>
<name>Template constructor cannot be a copy constructor, MISRA C++ Rule 14-5-2</name>
<description>Template constructor cannot be a copy constructor.</description>
</rule>
<rule>
<key>M14-5-3</key>
<configkey>M14-5-3</configkey>
<priority>INFO</priority>
<name>Operator =() for class is not assignment operator, MISRA C++ Rule 14-5-3</name>
<description>Operator =() for class is not assignment operator.</description>
</rule>
<rule>
<key>M14-6-1</key>
<configkey>M14-6-1</configkey>
<priority>INFO</priority>
<name>Unqualified name subject to misinterpretation, MISRA C++ Rule 14-6-1</name>
<description>Unqualified name subject to misinterpretation.</description>
</rule>
<!--
MISRA C++ rule 14-6-2 req n/a awaiting clarification from MISRA
-->
<rule>
<key>M14-7-1</key>
<configkey>M14-7-1</configkey>
<priority>INFO</priority>
<name>Template was defined but not instantiated, MISRA C++ Rule 14-7-1</name>
<description>Template was defined but not instantiated.</description>
</rule>
<!--
MISRA C++ rule 14-7-2 req no not currently supported
-->
<rule>
<key>M14-7-3</key>
<configkey>M14-7-3</configkey>
<priority>INFO</priority>
<name>Specialization occurs in different file than template, MISRA C++ Rule 14-7-3</name>
<description>Specialization occurs in different file than template.</description>
</rule>
<rule>
<key>M14-8-1</key>
<configkey>M14-8-1</configkey>
<priority>INFO</priority>
<name>Explicit specialization of overloaded function templates, MISRA C++ Rule 14-8-1</name>
<description>Explicit specialization of overloaded function templates.</description>
</rule>
<rule>
<key>M14-8-2</key>
<configkey>M14-8-2</configkey>
<priority>INFO</priority>
<name>Mixing template and non-template functions in a viable set, MISRA C++ Advisory Rule 14-8-2</name>
<description>Mixing template and non-template functions in a viable set.</description>
</rule>
<!--
MISRA C++ rule 15-0-1 doc n/a not statically checkable
-->
<rule>
<key>M15-0-2</key>
<configkey>M15-0-2</configkey>
<priority>INFO</priority>
<name>Throwing a pointer expression, MISRA C++ Advisory Rule 15-0-2</name>
<description>Throwing a pointer expression.</description>
</rule>
<rule>
<key>M15-0-3</key>
<configkey>M15-0-3</configkey>
<priority>INFO</priority>
<name>Case/default within loop; may have been misplaced, MISRA C++ Rule 15-0-3</name>
<description>Case/default within loop; may have been misplaced.</description>
</rule>
<!--
MISRA C++ rule 15-1-1 req no not currently supported
-->
<rule>
<key>M15-1-2</key>
<configkey>M15-1-2</configkey>
<priority>INFO</priority>
<name>Explicit throw of the NULL macro, MISRA C++ Rule 15-1-2</name>
<description>Explicit throw of the NULL macro.</description>
</rule>
<rule>
<key>M15-1-3</key>
<configkey>M15-1-3</configkey>
<priority>INFO</priority>
<name>Empty throw outside of a catch block, MISRA C++ Rule 15-1-3</name>
<description>Empty throw outside of a catch block.</description>
</rule>
<rule>
<key>M15-3-1</key>
<configkey>M15-3-1</configkey>
<priority>INFO</priority>
<name>Exception thrown within destructor, MISRA C++ Rule 15-3-1</name>
<description>Exception thrown within destructor.</description>
</rule>
<!--
MISRA C++ rule 15-3-2 adv no not currently supported
MISRA C++ rule 15-3-3 req no not currently supported
-->
<rule>
<key>M15-3-4</key>
<configkey>M15-3-4</configkey>
<priority>INFO</priority>
<name>Uncaught exception not on throw-list, MISRA C++ Rule 15-3-4</name>
<description>Uncaught exception not on throw-list.</description>
</rule>
<rule>
<key>M15-3-5</key>
<configkey>M15-3-5</configkey>
<priority>INFO</priority>
<name>Catch parameter is not a reference, MISRA C++ Rule 15-3-5</name>
<description>Catch parameter is not a reference.</description>
</rule>
<!--
MISRA C++ rule 15-3-6 req no not currently supported
-->
<rule>
<key>M15-3-7</key>
<configkey>M15-3-7</configkey>
<priority>INFO</priority>
<name>Catch handler after catch(...) in a try-catch sequence, MISRA C++ Rule 15-3-7</name>
<description>Catch handler after catch(...) in a try-catch sequence.</description>
</rule>
<rule>
<key>M15-4-1</key>
<configkey>M15-4-1</configkey>
<priority>INFO</priority>
<name>Exception specification conflict, MISRA C++ Rule 15-4-1</name>
<description>Exception specification conflict.</description>
</rule>
<rule>
<key>M15-5-1</key>
<configkey>M15-5-1</configkey>
<priority>INFO</priority>
<name>Exception thrown within destructor, MISRA C++ Rule 15-5-1</name>
<description>Exception thrown within destructor.</description>
</rule>
<rule>
<key>M15-5-2</key>
<configkey>M15-5-2</configkey>
<priority>INFO</priority>
<name>Exception not in throw-list of function, MISRA C++ Rule 15-5-2</name>
<description>Exception not in throw-list of function.</description>
</rule>
<rule>
<key>M15-5-3</key>
<configkey>M15-5-3</configkey>
<priority>INFO</priority>
<name>Exception thrown within destructor / uncaught exception not on throw-list, MISRA C++ Rule 15-5-3</name>
<description>Exception thrown within destructor / uncaught exception not on throw-list.</description>
</rule>
<rule>
<key>M16-0-1</key>
<configkey>M16-0-1</configkey>
<priority>INFO</priority>
<name>Only preprocessor statements and comments before '#include', MISRA C++ Rule 16-0-1</name>
<description>Only preprocessor statements and comments before '#include'.</description>
</rule>
<rule>
<key>M16-0-2</key>
<configkey>M16-0-2</configkey>
<priority>INFO</priority>
<name>'#define/#undef' used within a block, MISRA C++ Rule 16-0-2</name>
<description>'#define/#undef' used within a block.</description>
</rule>
<rule>
<key>M16-0-3</key>
<configkey>M16-0-3</configkey>
<priority>INFO</priority>
<name>Use of '#undef' is discouraged, MISRA C++ Rule 16-0-3</name>
<description>Use of '#undef' is discouraged.</description>
</rule>
<rule>
<key>M16-0-4</key>
<configkey>M16-0-4</configkey>
<priority>INFO</priority>
<name>Use of function-like macros is discouraged, MISRA C++ Rule 16-0-4</name>
<description>Use of function-like macros is discouraged.</description>
</rule>
<rule>
<key>M16-0-5</key>
<configkey>M16-0-5</configkey>
<priority>INFO</priority>
<name>Apparent preprocessor directive in macro, MISRA C++ Rule 16-0-5</name>
<description>apparent preprocessor directive in macro.</description>
</rule>
<rule>
<key>M16-0-6</key>
<configkey>M16-0-6</configkey>
<priority>INFO</priority>
<name>Unparenthesized parameter in macro is passed an expression, MISRA C++ Rule 16-0-6</name>
<description>Unparenthesized parameter in macro is passed an expression.</description>
</rule>
<rule>
<key>M16-0-7</key>
<configkey>M16-0-7</configkey>
<priority>INFO</priority>
<name>Undefined preprocessor variable, MISRA C++ Rule 16-0-7</name>
<description>Undefined preprocessor variable.</description>
</rule>
<rule>
<key>M16-0-8</key>
<configkey>M16-0-8</configkey>
<priority>INFO</priority>
<name>Unrecognized name after # / endif or else not followed by EOL, MISRA C++ Rule 16-0-8</name>
<description>Unrecognized name after # / endif or else not followed by EOL.</description>
</rule>
<rule>
<key>M16-1-1</key>
<configkey>M16-1-1</configkey>
<priority>INFO</priority>
<name>Non-standard use of 'defined' preprocessor operator, MISRA C++ Rule 16-1-1</name>
<description>Non-standard use of 'defined' preprocessor operator.</description>
</rule>
<rule>
<key>M16-1-2</key>
<configkey>M16-1-2</configkey>
<priority>INFO</priority>
<name>#if not closed off within file, MISRA C++ Rule 16-1-2</name>
<description>#if not closed off within file.</description>
</rule>
<!--
MISRA C++ rule 16-2-1 req no not currently supported
-->
<rule>
<key>M16-2-2</key>
<configkey>M16-2-2</configkey>
<priority>INFO</priority>
<name>Macro could become const variable, MISRA C++ Rule 16-2-2</name>
<description>Macro could become const variable.</description>
</rule>
<rule>
<key>M16-2-3</key>
<configkey>M16-2-3</configkey>
<priority>INFO</priority>
<name>Header file lacks standard include guard, MISRA C++ Rule 16-2-3</name>
<description>Header file lacks standard include guard.</description>
</rule>
<rule>
<key>M16-2-4</key>
<configkey>M16-2-4</configkey>
<priority>INFO</priority>
<name>Header file name with non-standard character, MISRA C++ Rule 16-2-4</name>
<description>Header file name with non-standard character.</description>
</rule>
<rule>
<key>M16-2-5</key>
<configkey>M16-2-5</configkey>
<priority>INFO</priority>
<name>header file name with non-standard character, MISRA C++ Advisory Rule 16-2-5</name>
<description>header file name with non-standard character.</description>
</rule>
<rule>
<key>M16-2-6</key>
<configkey>M16-2-6</configkey>
<priority>INFO</priority>
<name>need &< or " after #include, MISRA C++ Rule 16-2-6</name>
<description>need &< or " after #include.</description>
</rule>
<rule>
<key>M16-3-1</key>
<configkey>M16-3-1</configkey>
<priority>INFO</priority>
<name>Multiple use of '#' and/or '##' operators in macro definition/FlexeLint, MISRA C++ Rule 16-3-1</name>
<description>Multiple use of '#' and/or '##' operators in macro definition.</description>
</rule>
<rule>
<key>M16-3-2</key>
<configkey>M16-3-2</configkey>
<priority>INFO</priority>
<name>no use of ’#’ or ’##’, MISRA C++ Advisory Rule 16-3-2</name>
<description>no use of ’#’ or ’##’.</description>
</rule>
<!--
MISRA C++ rule 16-6-1 doc n/a not statically checkable
-->
<rule>
<key>M17-0-1</key>
<configkey>M17-0-1</configkey>
<priority>INFO</priority>
<name>complain about #define standard functions, MISRA C++ Rule 17-0-1</name>
<description>complain about #define standard functions.</description>
</rule>
<rule>
<key>M17-0-2</key>
<configkey>M17-0-2</configkey>
<priority>INFO</priority>
<name>Re-use of C++ identifier pattern, MISRA C++ Rule 17-0-2</name>
<description>Re-use of C++ identifier pattern.</description>
</rule>
<!--
MISRA C++ rule 17-0-3 req no not currently supported
-->
<rule>
<key>M17-0-4</key>
<configkey>M17-0-4</configkey>
<priority>INFO</priority>
<name>Use of +elib options to lint library code, MISRA C++ Rule 17-0-4</name>
<description>Use of +elib options to lint library code.</description>
</rule>
<rule>
<key>M17-0-5</key>
<configkey>M17-0-5</configkey>
<priority>INFO</priority>
<name>Do not use setjmp and longjmp, MISRA C++ Rule 17-0-5</name>
<description>Do not use setjmp and longjmp.</description>
</rule>
<rule>
<key>M18-0-1</key>
<configkey>M18-0-1</configkey>
<priority>INFO</priority>
<name>Do not use C library, MISRA C++ Rule 18-0-1</name>
<description>Do not use C library.</description>
</rule>
<rule>
<key>M18-0-2</key>
<configkey>M18-0-2</configkey>
<priority>INFO</priority>
<name>Do not use atof, atoi, atol, MISRA C++ Rule 18-0-2</name>
<description>Do not use atof, atoi, atol.</description>
</rule>
<rule>
<key>M18-0-3</key>
<configkey>M18-0-3</configkey>
<priority>INFO</priority>
<name>Do not use abort, exit, getenv, system, MISRA C++ Rule 18-0-3</name>
<description>Do not use abort, exit, getenv, system.</description>
</rule>
<rule>
<key>M18-0-4</key>
<configkey>M18-0-4</configkey>
<priority>INFO</priority>
<name>Do not use functions in ctime header, MISRA C++ Rule 18-0-4</name>
<description>Do not use functions in ctime header.</description>
</rule>
<rule>
<key>M18-0-5</key>
<configkey>M18-0-5</configkey>
<priority>INFO</priority>
<name>Do not use inbounded functions in cstring header, MISRA C++ Rule 18-0-5</name>
<description>Do not use inbounded functions in cstring header.</description>
</rule>
<rule>
<key>M18-2-1</key>
<configkey>M18-2-1</configkey>
<priority>INFO</priority>
<name>Do not use offsetof, MISRA C++ Rule 18-2-1</name>
<description>Do not use offsetof.</description>
</rule>
<rule>
<key>M18-4-1</key>
<configkey>M18-4-1</configkey>
<priority>INFO</priority>
<name>Do not use dynamic heap memory allocation functions, MISRA C++ Rule 18-4-1</name>
<description>Do not use dynamic heap memory allocation functions.</description>
</rule>
<rule>
<key>M18-7-1</key>
<configkey>M18-7-1</configkey>
<priority>INFO</priority>
<name>Do not use csignal functions, MISRA C++ Rule 18-7-1</name>
<description>Do not use csignal functions.</description>
</rule>
<rule>
<key>M19-3-1</key>
<configkey>M19-3-1</configkey>
<priority>INFO</priority>
<name>Do not use errno, MISRA C++ Rule 19-3-1</name>
<description>Do not use errno.</description>
</rule>
<rule>
<key>M27-0-1</key>
<configkey>M27-0-1</configkey>
<priority>INFO</priority>
<name>Do not use cstdio functions, MISRA C++ Rule 27-0-1</name>
<description>Do not use cstdio functions.</description>
</rule>
</rules>
