This file contains the text of the FlexeLint/PC-lint error messages.  It
is to be used in conjunction with licensed FlexeLint/PC-lint software.
Copyright (C) 1985-2008  Gimpel Software, All rights reserved

Gimpel Software  *  3207 Hogarth Lane  *  Collegeville, PA 19426
Phone (610) 584-4261  *  FAX (610) 584-4266  *  www.gimpel.com


    19.   MESSAGES

    19.1  Syntax Errors
    19.2  Internal Errors
    19.3  Fatal Errors
    19.4  Warning Messages
    19.5  Informational Messages
    19.6  Elective Notes
    19.7  C++ Syntax Errors
    19.8  Additional Internal Errors
    19.9  C++ Warning Messages
    19.10  C++ Informational Messages
    19.11  C++ Elective Notes



Most error messages have an associated error number.  By looking up the
number in the list below you can obtain additional information about the
cause of the error.  This information is also available from a
self-extracting executable msg.exe, found on the PC-lint
distribution diskette, which produces the machine-readable ASCII file
msg.txt.  For FlexeLint users, the file msg.txt can be found on
the FlexeLint Supplementary diskette.

Messages numbered 1000 and higher pertain generally to C++.  This is
summarized in the table below.

After a possible 1000 is subtracted off, the remainder lies in the range
0-999.  Remainders in the range 1-199 are syntax errors, 200-299 are PC-lint/FlexeLint
internal errors and should never occur, 300-399 are fatal errors usually
brought about by exceeding some limit, 400-699 are warning messages that
indicate that something is likely to be wrong with the program being
examined.  Remainders in the range 700-899 designate informational messages.
These may be errors but they also may represent legitimate programming
practices depending upon personal programming style.  Remainders in the
range 900-999 are called "Elective Notes".  They are not automatically
output.  You may examine the list to see if you wish to be alerted to
any of them.

                          C             C++           Warning Level

Syntax Errors            1 - 199     1001 - 1199           1
Internal Errors        200 - 299     1200 - 1299           0
Fatal Errors           300 - 399                           0
Warnings               400 - 699     1400 - 1699           2
Informational          700 - 899     1700 - 1899           3
Elective Notes         900 - 999     1900 - 1999           4


                                Glossary

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

argument  The actual argument of a function as opposed to a dummy (or
          formal) parameter of a function (see parameter).

arithmetic Any of the integral types (see below) plus float, double, and
           long double.

Boolean   In general, the word Boolean refers to quantities that can be
          either true or false.  An expression is said to be Boolean
          (perhaps it would be better to say 'definitely Boolean') if it
          is of the form: operand op operand where op is a relational (>
          >= < <=), an equality operator (== !=), logical And (&&) or
          logical Or (||).  A context is said to require a Boolean if it
          is used in an if or while clause or if it is the 2nd
          expression of a for clause or if it is an argument to one of
          the operators:  && or ||.  An expression needn't be definitely
          Boolean to be acceptable in a context that requires a Boolean.
          Any integer or pointer is acceptable.

declaration Gives properties about an object or function (as opposed to
            a definition).

definition That which allocates space for an object or function (as
           opposed to a declaration) and which may also indicate
           properties about the object.  There should be only one
           definition for an object but there may be many declarations.

integral  A type that has properties similar to integers.  These include
          char, short, int, and long and the unsigned variations of any
          of these.

scalar    Any of the arithmetic types plus pointers.

lvalue    Is an expression that can be used on the Left hand side of an
          assignment operator (=).  Some contexts require lvalues such
          as autoincrement (++) and autodecrement (--).

macro     An abbreviation defined by a #define statement.  It may or may
          not have arguments.

member    Elements of a struct and of a union are called members.

module    That which is compiled by a compiler in a single independent
          compilation.  It typically includes all the text of a .c (or a
          .cpp or .cxx, etc.) file plus any text within any #include
          file(s).

parameter A formal parameter of a function as opposed to an actual
          argument (see argument).


                           Message Parameters

Some of the messages are parameterized with one or more of the following
italicized names:

Char      Some character

Context   Specifies one of several contexts in which an assignment can
          be made.  Can be one of:

     o    assignment -- refers to an explicit assignment operator.
     o    return -- refers to the implied assignment of a return
          statement. The type of the expression is converted implicitly
          to the type of the function.
     o    initialization -- refers to the assignment implied by an
          initialization statement.
     o    arg. no.... -- refers to the implied assignment of an argument
          in the presence of a prototype.  The type of the expression is
          implicitly converted to the type within a prototype.
     o    arg. 'this' -- refers to the implied argument of a member
          function call.


FileName  A filename.  Messages containing this parameter can be
          suppressed with the -efile( ... ) option.

Integer   Some integer

Invocation A function call with argument types.  To suppress a message
           containing an Invocation you need the complete call, not just
           the function name.  For example, the call f(1) could result
           in Error 1024 parameterized by 'f(int)'.  To suppress this
           message you could use -esym(1024,f(int)).  You could also use
           wild cards as in -esym(1024,f*).

Kind      A list of control structures.

Location  A line number followed optionally by a filename (if different
          from the current) and/or a module name if different from the
          current.

Name      A string, usually an identifier, that can be suppressed with a
          -esym but not with -elibsym.

String    A sequence of characters identified further in the message
          description.

Symbol    The name of a user identifier referring to a C or C++ object
          such as variable, function, structure, etc.  Messages
          containing this parameter can be suppressed with the -esym(
          ... ) option.  For C++, if Symbol is the name of a function
          the full function signature (including parameters) is given.
          Error suppression with -esym does not require (nor want) the
          parameters.

Type      A type or a top type base is provided.  A top type base is one
          of pointer, function, array, struct, union, or enum.

TypeDiff  Specifies the way in which one type differs from another.
          Because of type qualification, function prototypes, and type
          compounding, it may not be obvious how two types differ.
          Also, see the -etd option to inhibit errors based on type
          differences.  TypeDiff can be one or more of:

     o    basic -- The two types differ in some fundamental way such as
          double versus int.

     o    count -- Two function types differ in the number of arguments.

     o    ellipsis -- Two function types differ in that one is
          prototyped using an ellipsis and the other is not prototyped.
          See Section 15.8 Plain Vanilla Functions.

     o    incomplete -- At least one of the types is only partially
          specified such as an array without a dimension or a function
          without a prototype.

     o    nominal -- The types are nominally different but are otherwise
          the same.  For example, int versus long where these are the
          same size or double versus long double where these are the
          same size.  The two types are either both integral or both
          float or are functions that return types or have arguments
          that differ nominally.  If long is the same size as int then
          unsigned long will differ from int both as nominal and as
          signed/unsigned.  If not the same size, then the difference is
          precision.

     o    origin -- The types are not actually different but have
          different origins.  For example a struct is defined in two
          separate modules rather than in one header file.  If for some
          reason you want to do this then use the option -etd(origin).

     o    precision -- Two arithmetic types differ in their precision
          such as int vs. long where these are different sizes.

     o    promotion -- Two function types differ in that one is
          prototyped with a char, short or float type and the other is
          not prototyped.

     o    ptrs to... -- Pointers point to different types, some TypeDiff
          code follows.

     o    ptrs to incompatible types -- Pointers point to types which in
          turn differ in precision, count, size, ellipsis or promotion.

     o    qualification -- Qualifiers such as const, volatile, etc. are
          inconsistent.

     o    signed/unsigned -- The types differ in that one is a signed
          integral type and the other is unsigned of the same size, or
          they are both functions that return types that differ in this
          way, or they are both pointers to types that differ in this
          way.

     o    size -- Two arrays differ in array dimension.

     o    strong -- two types differ in that one is strong and the other
          is not the same strong type.

     o    void/nonvoid -- The two types differ in that one is void and
          the other is not or, more frequently, they are both functions
          returning types that differ in this respect or pointers to
          types that differ in this respect.

     o    int/enum-- One type is an enum and the other is an int.

     o    Type = Type -- The two types in an assignment of some kind
          differ in some basic way and no more information is available.

     o    Type vs. Type -- The two types differ in some basic way and no
          more information is available.



19.1  C Syntax Errors

1      Unclosed Comment (Location)  -- End of file was reached with an
       open comment still unclosed.  The Location of the open comment is
       shown.

2      Unclosed Quote  -- An end of line was reached and a matching
       quote character (single or double) to an earlier quote character
       on the same line was not found.

3      #else without a #if  -- A #else was encountered not in the scope
       of a #if, #ifdef or #ifndef.

4      Too many #if levels  -- An internal limit was reached on the
       level of nesting of #if statements (including #ifdef and
       #ifndef).

5      Too many #endif's  -- A #endif was encountered not in the scope
       of a #if or #ifdef or #ifndef.

6      Stack Overflow  -- 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.

7      Unable to open include file: FileName  -- FileName is the name of
       the include file which could not be opened.

8      Unclosed #if (Location)  -- A #if (or #ifdef or #ifndef) was
       encountered without a corresponding #endif.  Location is the
       location of the #if.

9      Too many #else's in #if (Location)  -- A given #if contained a
       #else which in turn was followed by either another #else or a
       #elif.  The error message gives the line of the #if statement
       that started the conditional that contained the aberration.

10     Expecting 'String'  -- 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.

11     Excessive Size  -- The filename specified on a #include line had
       a length that exceeded FILENAME_MAX characters.

12     Need < or "  -- After a #include is detected and after macro
       substitution is performed, a file specification of the form
       <filename> or "filename" is expected.

13     Bad type  -- A type adjective such as long, unsigned, etc. cannot
       be applied to the type which follows.

14     Symbol 'Symbol' previously defined (Location)  -- 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.

15     Symbol 'Symbol' redeclared (TypeDiff) (Location)  -- 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.

16     Unrecognized name  -- A # directive is not followed by a
       recognizable word.  If this is not an error, use the +ppw option.

17     Unrecognized name  -- A non-parameter is being declared where
       only parameters should be.

18     Symbol 'Symbol' redeclared (TypeDiff) conflicts with Location  --
       A symbol is being redeclared.  The parameter TypeDiff provides
       further information on how the types differ.  Location is the
       location of the previous definition.

19     Useless Declaration  -- 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;;

20     Illegal use of =  -- A function declaration was followed by an =
       sign.

21     Expected {  -- An initializer for an indefinite size array must
       begin with a left brace.

22     Illegal operator  -- A unary operator was found following an
       operand and the operator is not a post operator.

23     Expected colon  -- A ? operator was encountered but this was not
       followed by a : as was expected.

24     Expected an expression, found 'String'  -- An operator was found
       at the start of an expression but it was not a unary operator.

25     Illegal constant  -- Too many characters were encountered in a
       character constant (a constant bounded by ' marks).

26     Expected an expression, found 'String'  -- An expression was not
       found where one was expected.  The unexpected token is placed in
       the message.

27     Illegal character (0xhh)  -- 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.

28     Redefinition of symbol 'Symbol' Location  -- The identifier
       preceding a colon was previously declared at the Location given
       as not being a label.

30     Expected a constant  -- 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.

31     Redefinition of symbol 'Symbol' conflicts with Location  -- A
       data object or function previously defined in this module is
       being redefined.

32     Field size (member 'Symbol') should not be zero  -- The length of
       a field was given as non-positive, (0 or negative).

33     Illegal constant  -- A constant was badly formed as when an octal
       constant contains one of the digits 8 or 9.

34     Non-constant initializer  -- A non-constant initializer was found
       for a static data item.

35     Initializer has side-effects  -- An initializer with side effects
       was found for a static data item.

36     Redefining the storage class of symbol 'Symbol' conflicts with
       Location  -- An object's storage class is being changed.

37     Value of enumerator 'Symbol' inconsistent (conflicts with
       Location)  -- An enumerator was inconsistently valued.

38     Offset of symbol 'Symbol' inconsistent (Location)  -- 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.

39     Redefinition of symbol 'Symbol' conflicts with Location  -- A
       struct or union is being redefined.

40     Undeclared identifier 'Name'  -- 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.

41     Redefinition of symbol 'Symbol'  -- A parameter of either a
       function or a macro is being repeated.

42     Expected a statement  -- A statement was expected but a token was
       encountered that could not possibly begin a statement.

43     Vacuous type for variable 'Symbol'  -- A vacuous type was found
       such as the void type in a context that expected substance.

44     Need a switch  -- A case or default statement occurred outside a
       switch.

45     Bad use of register  -- A variable is declared as a register but
       its type is inconsistent with it being a register (such as a
       function).

46     Field type should be int  -- 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.

47     Bad type  -- Unary minus requires an arithmetic operand.

48     Bad type  -- Unary * or the left hand side of the ptr (->)
       operator requires a pointer operand.

49     Expected a type  -- 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.

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

51     Expected integral type  -- Unary ~ expects an integral type
       (signed or unsigned char, short, int, or long).

52     Expected an lvalue  -- 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).

53     Expected a scalar  -- Autodecrement (--) and autoincrement (++)
       operators may only be applied to scalars (arithmetics and
       pointers) or to objects for which these operators have been
       defined.

54     Division by 0  -- The constant 0 was used on the right hand side
       of the division operator (/) or the remainder operator (%).

55     Bad type  -- The context requires a scalar, function, array, or
       struct (unless -fsa).

56     Bad type  -- Add/subtract operator requires scalar types and
       pointers may not be added to pointers.

57     Bad type  -- Bit operators ( &, | and ^ ) require integral
       arguments.

58     Bad type  -- Bad arguments were given to a relational operator;
       these always require two scalars and pointers can't be compared
       with integers (unless constant 0).

59     Bad type  -- The amount by which an item can be shifted must be
       integral.

60     Bad type  -- The value to be shifted must be integral.

61     Bad type  -- The context requires a Boolean.  Booleans must be
       some form of arithmetic or pointer.

62     Incompatible types (TypeDiff) for operator ':'  -- The 2nd and
       3rd arguments to ? : must be compatible types.

63     Expected an lvalue  -- Assignment expects its first operand to be
       an lvalue.  Please note that a cast removes the lvaluedness of an
       expression.

64     Type mismatch (Context) (TypeDiff)  -- There was a mismatch in
       types across an assignment (or implied assignment, see Context).
       TypeDiff specifies the type difference.

65     Expected a member name  -- After a dot (.) or pointer (->)
       operator a member name should appear.

66     Bad type  -- 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.)

67     Can't cast from Type to Type  -- Attempt to cast a non-scalar to
       an integral.

68     Can't cast from Type to Type  -- Attempt to cast a non-arithmetic
       to a float.

69     Can't cast from Type to Type  -- Bad conversion involving
       incompatible structures or a structure and some other object.

70     Can't cast from Type to Type  -- Attempt to cast to a pointer
       from an unusual type (non-integral).

71     Can't cast from Type to Type  -- Attempt to cast to a type that
       does not allow conversions.

72     Bad option 'String'  -- Was not able to interpret an option.  The
       option is given in String.

73     Bad left operand  -- 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.

74     Address of Register  -- An attempt was made to apply the address
       (&) operator to a variable whose storage class was given as
       register.

75     Too late to change sizes (option 'String')  -- 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.

76     can't open file  String  -- 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.

77     Address of bit-field cannot be taken  -- 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).

78     Symbol 'Symbol' typedef'ed at Location used in expression  -- 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.

79     Bad type for % operator  -- The % operator should be used with
       some form of integer.

80     this use of ellipsis is not strictly ANSI  -- 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.

81     struct/union not permitted in equality comparison  -- 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.

82     return <exp>; illegal with void function  -- 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.

83     Incompatible pointer types with subtraction  -- 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.

84     sizeof object is zero or object is undefined  -- 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.

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

86     Structure 'Symbol' has no data elements  -- A structure was
       declared (in a C module) that had no data members.  Though legal
       in C++ this is not legal C.

87     Expression too complicated for #ifdef or #ifndef  -- 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.

88     Symbol 'Symbol' is an array of empty elements  -- An array was
       declared (in a C module) whose elements were each of 0 length.
       Though legal in C++ this is not permitted C.

89     Argument or option too long ('String')  -- 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.

90     Option 'String' is only appropriate within a lint comment  -- 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.

91     Line exceeds Integer characters (use +linebuf)  -- 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.

92     Negative array dimension or bit field length (Integer)  -- A
       negative array dimension or bit field length is not permitted.

93     New-line is not permitted within string arguments to macros  -- 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.

95     Expected a macro parameter but instead found 'Name'  -- 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.

96     Unmatched left brace for String on Location  -- 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.

98     Recovery Error (String)  -- 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.

101    Expected an identifier  -- 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.

102    Illegal parameter specification  -- Within a function declarator,
       a parameter must be specified as either an identifier or as a
       type followed by a declarator.

103    Unexpected declaration  -- 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.

104    Conflicting types  -- Two consecutive conflicting types were
       found such as int followed by double.  Remove one of the types!

105    Conflicting modifiers  -- Two consecutive conflicting modifiers
       were found such as far followed by near.  Remove one of the
       modifiers!

106    Illegal constant  -- A string constant was found within a
       preprocessor expression as in

               #if ABC == "abc"

       Such expressions should be integral expressions.

107    Label 'Symbol' (Location) not defined  -- The Symbol at the given
       Location appeared in a goto but there was no corresponding label.

108    Invalid context  -- 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.

109    The combination 'short long' is not standard, 'long' is assumed
       -- 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.

110    Attempt to assign to void  -- An attempt was made to assign a
       value to an object designated (possibly through a pointer) as
       void.

111    Assignment to const object  -- 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.

113    Inconsistent enum declaration  -- 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.

114    Inconsistent structure declaration for tag 'Symbol'  -- The
       sequence of members within a structure (or union) is inconsistent
       with another structure (usually in some other module) having the
       same name.

115    Struct/union not defined  -- 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.

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

117    Inappropriate storage class  -- A storage class was provided
       outside any function that indicated either auto or register.
       Such storage classes are appropriate only within functions.

118    Too few arguments for prototype  -- The number of arguments
       provided for a function was less than the number indicated by a
       prototype in scope.

119    Too many arguments for prototype  -- The number of arguments
       provided for a function was greater than the number indicated by
       a prototype in scope.

120    Initialization without braces of dataless type 'Symbol'  -- 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
     

121    Attempting to initialize an object of undefined type 'Symbol'  --
       The initialization of an object was attempted where that object
       type has no visible definition.  For example:
     
             class Undefined u = { 5 };
     

122    Digit (Char) too large for radix  -- 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.

123    Macro 'Symbol' defined with arguments at Location this is just a
       warning  -- 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.

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

125    Too many storage class specifiers  -- More than one storage class
       specifier (static, extern, typedef, register or auto) was found.
       Only one is permitted.

126    Inconsistent structure definition 'Symbol'  -- 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.

127    Illegal constant  -- An empty character constant ('') was found.

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

129    declaration expected, identifier 'Symbol' ignored  -- In a
       context in which a declaration was expected an identifier was
       found.  Moreover, the identifier was not followed by '(' or a '['

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

131    syntax error in call of macro 'Symbol' at location Location  --
       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.

132    Expected function definition  -- 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.

133    Too many initializers for aggregate 'Symbol'  -- In a
       brace-enclosed initializer, there are more items than there are
       elements of the aggregate.

134    Missing initializer  -- An initializer was expected but only a
       comma was present.

135    comma assumed in initializer  -- 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 (}).

136    Illegal macro name  -- The ANSI standard restricts the use of
       certain names as macros.  defined is on the restricted list.

137    constant 'Symbol' used twice within switch  -- The indicated
       constant was used twice as a case within a switch statement.
       Currently only enumerated types are checked for repeated
       occurrence.

138    Can't add parent 'Symbol' to strong type String; creates loop  --
       An attempt was made to add a strong type parent to a typedef
       type.  The attempt is either explicit (with the -strong option)
       or implicit with the use of a typedef to a known strong type.
       This attempt would have caused a loop in the strong parent
       relationship.  Such loops are simply not tolerated.

139    Can't take sizeof function  -- There is an attempt to take the
       sizeof a function.

140    Type appears after modifier  -- 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.

141    The following option has too many elements: 'String'  -- 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.

143    Erroneous option: String  -- 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.

144    Non-existent return value for symbol 'Symbol', compare with
       Location  -- 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.

145    Type expected before operator, void assumed  -- 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.

146    Assuming a binary constant  -- 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.

147    sizeof takes just one argument  -- 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.

148    member 'Symbol' previously declared at Location  -- 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.

149    C++ construct 'String' found in C code  -- 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.

150    Token 'String' unexpected String  -- An unexpected token was
       encountered.  The action taken, if any, is identified by the
       second message parameter.

151    Token 'Name' inconsistent with abstract type  -- 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;

152    Lob base file 'file name' missing  -- 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.

153    Could not create temporary file  -- 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().

154    Could not evaluate type 'String', int assumed  -- 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.

155    Ignoring { }'ed sequence within an expression, 0 assumed  -- 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.

156    Braced initializer for scalar type 'Name'  -- 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.

157    No data may follow an incomplete array  -- An incomplete array is
       allowed within a struct of a C99 or C++ program but no data is
       allowed to appear after this array.  For example:
     
             struct A { int x; int a[]; int b; };
     
       This diagnostic is issued when the 'b' is seen.

158    Assignment to variable 'Symbol' (Location) increases capability
       -- 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.

159    enum following a type is non-standard  -- 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.

160    The sequence '( {' is non standard and is taken to introduce a
       GNU statement expression  -- 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).

161    Repeated use of parameter 'Symbol' in parameter list  -- The name
       of a function parameter was repeated.  For example:
     
                 void f( int n, int m, int n ) {}
     
       will cause this message to be issued.  Names of parameters for a
       given function must all be different.


19.2  Internal Errors

2XX    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.



19.3  Fatal Errors

Errors in this category are normally fatal and suppressing the error is
normally impossible.  However, those errors marked with an asterisk(*)
can be suppressed and processing will be continued.  For example -e306
will allow reprocessing of modules.


301    Stack overflow  -- 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.

302    Exceeded Available Memory  -- Main memory has been exhausted.

303    String too long (try +macros)  -- 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.

304    Corrupt object file, code Integer, symbol=String  -- 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.

305    Unable to open module 'file name'  -- file name is the name of
       the file.  The named module could not be opened for reading.
       Perhaps you misspelled the name.

306    Previously encountered module 'FileName'  -- FileName is the name
       of the module.  The named module was previously encountered.
       This is probably a user blunder.

307    Can't open indirect file 'FileName'  -- FileName is the name of
       the indirect file.  The named indirect file (ending in .lnt)
       could not be opened for reading.

308    Can't write to standard out  -- stdout was found to equal NULL.
       This is most unusual.

309    #error ...  -- 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.

310    Declaration too long: 'String...'  -- 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.

312    Lint Object Module has obsolete or foreign version id: Integer
       -- 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.

313    Too many files  -- 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.

314    Previously used .lnt file: FileName  -- The indirect file named
       was previously encountered.  If this was not an accident, you may
       suppress this message.

315    Exceeded message limit (see -limit)  -- The maximum number of
       messages was exceeded.  Normally there is no limit unless one is
       imposed by the -limit(n) option.

316    Error while writing to file "file name"  -- The given file could
       not be opened for output.

317    File encoding, String, not currently supported  -- 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).

321    Declaration stack overflow  -- An overflow occurred in the stack
       used to contain array, pointer, function or reference modifiers
       when processing a declarator.

322    Unable to open include file FileName  -- 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.

323    Token String too long  -- In attempting to save a token for later
       reuse, a fixed size buffer was exceeded (governed by the size
       M_TOKEN).

324    Too many symbols Integer  -- Too many symbols were encountered.
       An internal limit was reached.

325    Cannot re-open file 'file name'  -- 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.

326    String 'String ...' too long, exceeds Integer characters  -- 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.

328    Bypass header 'Name' follows a different header sequence than in
       module 'String' which includes File1 where the current module
       includes File2  -- 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.


19.4  C Warning Messages

401    symbol 'Symbol' not previously declared static at Location  --
       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.

402    static function 'Symbol' (Location) not defined  -- The named
       Symbol was declared as a static function in the current module
       and was referenced but was not defined (in the module).

403    static symbol 'Symbol' has unusual type modifier  -- Some type
       modifiers such as _export are inconsistent with the static
       storage class.

404    struct not completed within file 'FileName'  -- A struct (or
       union or enum) definition was started within a header file but
       was not completed within the same header file.

405    #if not closed off within file 'FileName'  -- An #if construct
       was begun within a header file (name given) but was not completed
       within that header file.  Was this intentional?

406    Comment not closed off within file 'FileName'  -- A comment was
       begun within a header file (name given) but was not completed
       within that header file.  Was this intentional?

407    Inconsistent use of tag 'Symbol' conflicts with Location  -- 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.

408    Type mismatch with switch expression  -- The expression within a
       case does not agree exactly with the type within the switch
       expression.  For example, an enumerated type is matched against
       an int.

409    Expecting a pointer or array  -- 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.

410    size_t not what was expected from fzl and/or fzu, using 'Type'
       -- This warning is issued if you had previously attempted to set
       the type of sizeof by use of the options +fzl, -fzl, or -fzu, and
       a later size_t declaration contradicts the setting.  This usually
       means you are attempting to lint programs for another system
       using header 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.

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

412    Ambiguous format specifier '%X'  -- 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.

413    Likely use of null pointer 'Symbol' in [left/right] argument to
       operator 'String' Reference  -- 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.

414    Possible division by 0  -- 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.

415    access of out-of-bounds pointer ('Integer' beyond end of data) by
       operator 'String'  -- 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'.

416    creation of out-of-bounds pointer ('Integer' beyond end of data)
       by operator 'String'  -- 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.

417    integral constant 'String' has precision Number which is longer
       than long long int  -- 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.

418    Passing null pointer to function 'Symbol', Context Reference  --
       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.

419    Apparent data overrun for function 'Symbol', argument Integer
       exceeds argument Integer  -- 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.

420    Apparent access beyond array for function 'Symbol', argument
       Integer exceeds Integer Reference  -- 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.

421    Caution -- function 'Symbol' is considered dangerous  -- This
       message is issued (by default) for the built-in function gets.
       This function is considered dangerous because there is no
       mechanism to ensure that the 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.

422    Passing to function 'Symbol' a negative value (Integer), Context
       Reference  -- 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.

423    Creation of memory leak in assignment to variable 'Symbol'  -- 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.

424    Inappropriate deallocation (Name1) for 'Name2' data.  -- 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

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

426    Call to function 'Symbol' violates semantic 'String'  -- 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)'

427    // comment terminates in \  -- 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 (//).

428    negative subscript (Integer) in operator 'String'  -- 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.

429    Custodial pointer 'Symbol' (Location) has not been freed or
       returned  -- A pointer of auto storage class was allocated
       storage which was neither freed nor returned to the caller.  This
       represents a "memory leak".  A pointer is considered custodial if
       it uniquely points to the storage area.  It is not considered
       custodial if it has been copied.  Thus:
       
               int *p = new int[20];  // p is a custodial pointer
               int *q = p;            // p is no longer custodial
               p = new int[20];       // p again becomes custodial
               q = p + 0;             // p remains custodial

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

       A pointer can lose its custodial property by passing the pointer
       to a function.  If the parameter of the function is typed pointer
       to const or if the function is a library function, that
       assumption is not made.  For example
       
               p = malloc(10);
               strcpy (p, "hello");

       Then p still has custody of storage allocated.

       It is possible to indicate via semantic options that a function
       will take custody of a pointer.

430    Character '@', taken to specify variable location, is not
       standard C/C++  -- 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.

431    Missing identifier for template parameter number Integer  -- A
       template object parameter (as opposed to a type parameter) was
       not provided with an identifier.  Was this an oversight?

432    Suspicious argument to malloc  -- 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 )

433    Allocated area not large enough for pointer  -- 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.

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

       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 */

435    integral constant 'String' has precision Integer, use +fll to
       enable long long"  -- 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.

436    Apparent preprocessor directive in invocation of macro 'Symbol'
       -- 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.

437    Passing struct 'Symbol' to ellipsis  -- 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.

438    Last value assigned to variable 'Symbol' not used  -- A value had
       been assigned to a variable that was not subsequently used.  The
       message is issued either at a return statement or at the end of a
       block when the variable goes out of scope.  For example, consider
       the following function:
       
                 void f( int n )
                     {
                     int x = 0, y = 1;
                     if( n > 0 )
                         {
                         int z;
                         z = x + y;
                         if( n > z ) { x = 3; return; }
                         z = 12;
                         }
                     }
       
       Here we can report that x was assigned a value that had not been
       used by the time the return statement had been encountered.  We
       also report that the most recently assigned value to z is unused
       at the point that z goes out of scope.  See 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).

440    for clause irregularity: variable 'Symbol' tested in 2nd
       expression does not match 'Symbol' modified in 3rd  -- 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.

441    for clause irregularity: loop variable 'Symbol' not found in 2nd
       for expression  -- 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.

442    for clause irregularity: testing direction inconsistent with
       increment direction  -- A for clause was encountered that
       appeared to have a parity problem.  For example:
       
                 for( i = 0; i < 10; i-- )
                     ...
       
       Here the test for i less than 10 seems inconsistent with the 3rd
       expression of the for clause which decreases the value of i.
       This same message would be given if i were being increased by the
       3rd expression and was being tested for being greater than some
       value in the 2nd expression.

443    for clause irregularity: variable 'Symbol' initialized in 1st
       expression does not match 'Symbol' modified in 3rd  -- 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.

444    for clause irregularity: pointer 'Symbol' incremented in 3rd
       expression is tested for NULL in 2nd expression  -- 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.

445    reuse of for loop variable 'Symbol' at 'Location' could cause
       chaos  -- 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++ ) { ... }
                     }
       
446    for loop index variable 'Symbol' modified in body of the for loop
       -- 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 */
       

447    Extraneous whitespace ignored in include directive for file
       'FileName'; opening file 'FileName'  -- 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.

448    Likely access of pointer pointing Integer bytes past nul
       character by operator 'String'  -- Accessing past the terminating
       nul character is often an indication of a programmer error.  For
       example:
       
                 char buf[20];
                 strcpy( buf, "a" );
                 char c = buf[4];   // legal but suspect.
       
       Although buf has 20 characters, after the strcpy, there would be
       only two that the programmer would normally be interested in.

449    Pointer variable 'Symbol' previously deallocated  -- A pointer
       variable (designated in the message) was freed or deleted in an
       earlier statement.

451    Header file 'FileName' repeatedly included but does not have a
       standard include guard  -- 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.

452    typedef Symbol 'Symbol' redeclared (TypeDiff) conflicts with
       Location",  -- 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.

453    Function 'Symbol', previously designated pure, String 'Name'  --
       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.

454    A thread mutex has been locked but not unlocked  -- 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
                     ...
       
455    A thread mutex that had not been locked is being unlocked  -- 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
                     }
       
456    Two execution paths are being combined with different mutex lock
       states  -- 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.

457    Function 'Symbol1' of thread 'Symbol2' has an unprotected write
       access to variable 'Symbol3' which is used by function 'Symbol4'
       of thread 'Symbol5'  -- 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.

458    Function 'Symbol1' of thread 'Symbol2' has an unprotected read
       access to variable 'Symbol3' which is modified by function
       'Symbol4' of thread 'Symbol5'  -- 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.

459    Function 'Symbol' whose address was taken has an unprotected
       access to variable 'Symbol'  -- 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.

460    Thread 'Symbol' has unprotected call to thread unsafe function
       'Symbol' which is also called by thread 'Symbol'  -- 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.

461    Thread 'Symbol' has unprotected call to function 'Symbol' of
       group 'Name' while thread 'Symbol' calls function 'Symbol' of the
       same group  -- 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.

462    Thread 'Symbol' calling function 'Symbol' is inconsistent with
       the 'String' semantic  -- 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.

464    Buffer argument will be copied into itself  -- 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 );
       

501    Expected signed type  -- The unary minus operator was applied to
       an unsigned type.  The resulting value is a positive unsigned
       quantity and may not be what was intended.

502    Expected unsigned type  -- Unary ~ being a bit operator would
       more logically be applied to unsigned quantities rather than
       signed quantities.

503    Boolean argument to relational  -- Normally a relational would
       not have a Boolean as argument.  An example of this is a < b < c
       which is technically legal but does not produce the same result
       as the mathematical expression which it resembles.

504    Unusual shift operation (String)  -- Either the quantity being
       shifted or the amount by which a quantity is to be shifted was
       derived in an unusual way such as with a bit-wise logical
       operator, a negation, or with an unparenthesized expression.  If
       the shift value is a compound expression that is not
       parenthesized, parenthesize it.

505    Redundant left argument to comma  -- The left argument to the
       comma operator had no side effects in its top-most operator and
       hence is redundant.

506    Constant value Boolean  -- 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.

507    Size incompatibility  -- 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.

508    extern used with definition  -- 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.

509    extern used with definition  -- 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.

511    Size incompatibility  -- 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.

512    Symbol 'Symbol' previously used as static (Location)  -- 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.

514    Unusual use of a Boolean  -- 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).

515    Symbol 'Symbol' has arg. count conflict (Integer vs. Integer)
       with Location  -- 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.

516    Symbol 'Symbol' has arg. type conflict (no. Integer -- TypeDiff)
       with Location  -- 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.

517    defined not K&R  -- 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.

518    Expected '('  -- sizeof type is not strict C.  sizeof(type) or
       sizeof expression are both permissible.

519    Size incompatibility  -- 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.

520    Highest operator or function lacks side-effects  -- 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).

521    Highest operator or function lacks side-effects  -- 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).

522    Highest operator or function lacks side-effects  -- 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

524    Loss of precision (Context) (Type to Type)  -- 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.

525    Negative indentation from Location  -- 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.

526    'Symbol' (Location) not defined  -- 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.

527    Unreachable code at token Symbol  -- A portion of the program
       cannot be reached.

528    Symbol 'Symbol' (Location) not referenced  -- The named static
       variable or static function was not referenced in the module
       after having been declared.

529    Symbol 'Symbol' (Location) not subsequently referenced  -- The
       named variable was declared but not referenced in a function.

530    Symbol 'Symbol' (Location) not initialized  -- An auto variable
       was used before it was initialized.

531    Field size too large for 'Symbol'  -- The size given for a bit
       field of a structure exceeds the size of an int.

532    Return mode of function 'Symbol' inconsistent with Location  -- 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.

533    function 'Symbol' should (not) return a value (see Location)  --
       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.)

534    Ignoring return value of function 'Symbol' (compare with
       Location)  -- 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.

537    Repeated include file 'FileName'  -- 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.

538    Excessive size  -- The size of an array equals or exceeds 64K
       bytes.

539    Did not expect positive indentation from Location  -- 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.

540    Excessive size  -- A string initializer required more space than
       what was allocated.

541    Excessive size  -- 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.

542    Excessive size for bit field  -- 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.

544    endif or else not followed by EOL  -- 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.

545    Suspicious use of &  -- 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.

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

547    Redefinition of symbol 'Symbol' conflicts with Location  -- The
       indicated symbol had previously been defined (vis #define)to some
       other value.

548    else expected  -- 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.

549    Suspicious cast  -- 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.

550    Symbol 'Symbol' (Location) not accessed  -- A variable (local to
       some function) was not accessed.  This means that the value of a
       variable was never used.  Perhaps the variable was assigned a
       value but was never used.  Note that a variable's value is not
       considered accessed by autoincrementing or autodecrementing
       unless the autoincrement/decrement appears within a larger
       expression which uses the resulting value.  The same applies to a
       construct of the form: var += expression.  If an address of a
       variable is taken, its value is assumed to be accessed. An array,
       struct or union is considered accessed if any portion thereof is
       accessed.

551    Symbol 'Symbol' (Location) not accessed  -- A variable (declared
       static at the module level) was not accessed though the variable
       was referenced.  See the explanation under message 550 (above)
       for a description of "access".

552    Symbol 'Symbol' (Location) not accessed  -- An external variable
       was not accessed though the variable was referenced.  See the
       explanation under message 550 above for a description of
       "access".

553    Undefined preprocessor variable 'Name', assumed 0  -- 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.

555    #elif not K&R  -- 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.

556    indented #  -- 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 #.

557    unrecognized format  -- 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).

558    Too few arguments for format (Integer missing)   -- 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.

559    size of argument number Integer inconsistent with format  -- 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.

560    argument no. Integer should be a pointer  -- 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.

561    (arg. no. Integer) indirect object inconsistent with format  --
       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.

562    Ellipsis (...) assumed  -- 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.

563    Label 'Symbol' (Location) not referenced  -- The Symbol at the
       cited Location appeared as a label but there was no statement
       that referenced this label.

564    variable 'Symbol' depends on order of evaluation  -- 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.

565    tag 'Symbol' not previously seen, assumed file-level scope  --
       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.

566    Inconsistent or redundant format char 'Char'  -- 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.

567    Expected a numeric field before char 'Char'  -- 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.

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

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

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

569    Loss of information (Context) (Integer bits to Integer bits)  --
       An assignment (or implied assignment, see Context) was made from
       a constant to an integral variable that is not large enough to
       hold the constant.  Examples include placing a hex constant whose
       bit requirement is such as to require an unsigned int into a
       variable typed as int.  The number of bits given does not count
       the sign bit.

570    Loss of sign (Context) (Type to Type)  -- An assignment (or
       implied assignment, see Context) is being made from a negative
       constant into an unsigned quantity.  Casting the constant to
       unsigned will remove the diagnostic but is this what you want.
       If you are assigning all ones to an unsigned, remember that ~0
       represents all ones and is more portable than -1.

571    Suspicious Cast  -- 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.

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

               ch >> 10

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

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

               u / n

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

               u / 4

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

               n = n / u

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

       To resolve this problem, either cast the integer to unsigned if
       you know it can never be less than zero or cast the unsigned to
       an integer if you know it can never exceed the maximum integer.

574    Signed-unsigned mix with relational  -- The four relational
       operators are:
               >   >=   <   <=

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

               if( u > n ) ...

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

               if( u > 12 ) ...

       will not (even though 12 is 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.

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

577    Mixed memory model (option 'String')  -- 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.

578    Declaration of symbol 'Symbol' hides symbol 'Symbol' (Location)
       -- 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.

579    parameter preceding ellipsis has invalid type  -- 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.

580    Redeclaration of function 'Symbol' (hiding Location) causes loss
       of prototype  -- A declaration of a function within a block hides
       a declaration in an outer scope in such a way that the inner
       declaration has no prototype and the outer declaration does.  A
       common misconception is that the resulting declaration is a
       composite of both declarations but this is only the case when the
       declarations are in the same scope not within nested scopes.  If
       you don't care about prototypes you may suppress this message.
       You will still receive other type-difference warnings.

581    Option 'String' is obsolete and should no longer be used  -- This
       message is issued whenever we encounter an option that appears to
       do more harm than good.  'String' is the option in question.

582    esym (or emacro) name 'String' should not contain '('  -- 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.

583    Comparing type 'Type' with EOF  -- 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.

584    Trigraph sequence (??Char) detected  -- 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.

585    The sequence (??Char) is not a valid Trigraph sequence  -- This
       warning is issued whenever a pair of '?' characters is seen
       within a string (or character) constant but that pair is not
       followed by a character which would make the triple a valid
       Trigraph sequence.  Did the programmer intend this to be a
       Trigraph sequence and merely err?  Even if no Trigraph were
       intended, it can easily be mistaken by the reader of the code to
       be a Trigraph.  Moreover, what assurances do we have that in the
       future the invalid Trigraph might not become a valid Trigraph and
       change the meaning of the string? To protect yourself from such
       an event you may place a backslash between the '?' characters.
       Alternatively you may use concatenation of string constants.  For
       example:
       
                 pattern = "(???) ???-????";         // warning 585
                 pattern = "(?\?\?) ?\?\?-?\?\?\?";  // no warning
                 #define Q "?"
                 pattern = "(" Q Q Q ") " Q Q Q "-" Q Q Q Q  // no warning
       
586    String 'Name' is deprecated. String  -- 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.

587    Predicate 'String' can be pre-determined and always evaluates to
       String  -- 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'.

588    Predicate 'String' will always evaluate to String unless an
       overflow occurs  -- 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.

589    Predicate 'String' will always evaluate to String assuming
       standard division semantics  -- 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.

590    Predicate 'String' will always evaluate to String assuming
       standard shift semantics  -- 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.

591    Variable 'Symbol' depends on the order of evaluation; it is
       used/modified through function 'Symbol' via calls: String"  --
       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.

592    Non-literal format specifier used without arguments  -- 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.

593    Custodial pointer 'Symbol' (Location) possibly not freed or
       returned  -- This is the 'possible' version of message 429.  A
       pointer of auto storage class was allocated storage and not all
       paths leading to a return statement or to the end of the function
       contained either a free or a return of the pointer.  Hence there
       is a potential memory leak.  For example:
       
         void f( int n )
             {
             int *p = new int;
             if( n ) delete p;
             }                   // message 593
       
       In this example an allocation is made and, if n is 0, no delete
       will have been made.

       Please see message 429 for an explaination of "custodial" and
       ways of regulating when pointer variables retain custody of
       allocations.

601    Expected a type for symbol Symbol, int assumed  -- A declaration
       did not have an explicit type.  int was assumed.  Was this a
       mistake?  This could easily happen if an intended comma was
       replaced by a semicolon.  For example, if instead of typing:
       
               double       radius,
                            diameter;
       
       the programmer had typed:
       
               double       radius;
                            diameter;
       
       this message would be raised.

602    Comment within comment  -- 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.

603    Symbol 'Symbol' (Location) not initialized  -- 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.

604    Returning address of auto variable 'Symbol'  -- The address of
       the named symbol is being passed back by a function.  Since the
       object is an auto and since the duration of an auto is not
       guaranteed past the return, this is most likely an error.  You
       may want to copy the value into a global variable and pass back
       the address of the global or you might consider having the caller
       pass an address of one of its own variables to the callee.

605    Increase in pointer capability (Context)  -- This warning is
       typically caused by assigning a (pointer to const) to an ordinary
       pointer.  For example:
       
               int *p;
               const int *q;
               p = q;      /* 605 */
       
       The message will be inhibited if a cast is used as in:

               p = (int *) q;

       An increase in capability is indicated because the const pointed
       to by q can now be 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.

606    Non-ANSI escape sequence: '\String'  -- 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

607    Parameter 'Symbol' of macro found within string  -- 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.

608    Assigning to an array parameter  -- 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.

609    Suspicious pointer conversion  -- 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.

610    Suspicious pointer combination  -- 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.

611    Suspicious cast  -- 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.

612    Expected a declarator  -- 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.

613    Possible use of null pointer 'Symbol' in [left/right] argument to
       operator 'String' Reference  -- 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.

614    auto aggregate initializer not constant  -- 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.

615    auto aggregate initializer has side effects  -- 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.

616    control flows into case/default  -- 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.

617    String is both a module and an include file  -- 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.

618    Storage class specified after a type  -- 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.

619    Loss of precision (Context) (Pointer to Pointer)  -- 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.

620    Suspicious constant (L or one?)  -- A constant ended in a
       lower-case letter 'l'.  Was this intended to be a one?  The two
       characters look very similar.  To avoid misinterpretations, use
       the upper-case letter 'L'.

621    Identifier clash (Symbol 'Name' with Symbol 'Name' at String)  --
       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.

622    Size of argument no. Integer inconsistent with format  -- 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).

623    redefining the storage class of symbol 'Symbol' (TypeDiff)
       conflicts with Location  -- 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?

624    typedef 'Symbol' redeclared (TypeDiff) (Location)  -- A symbol
       was declared in a typedef differently in two different modules.
       This is technically legal but is not a wise programming practice.

625    auto symbol 'Symbol' has unusual type modifier  -- Some type
       modifiers such as far, near, fortran are inappropriate for auto
       variables.

626    argument no. Integer inconsistent with format  -- 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.

627    (arg. no. Integer) indirect object inconsistent with format  --
       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.

628    no argument information provided for function 'Symbol' (Location)
       -- 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.

629    static class for function 'Symbol' is non standard  -- 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.

630    ambiguous reference to symbol 'Name'  -- 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.

631    tag 'Symbol' defined differently at Location  -- 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.

632    Assignment to strong type 'Name' in context: Context  -- An
       assignment (or implied assignment, Context indicates which)
       violates a Strong type check as requested by a -strong(A...
       option.

633    Assignment from a strong type 'Name' in context: Context  -- An
       assignment (or implied assignment, Context indicates which)
       violates a Strong type check as requested by a -strong(X...
       option.

634    Strong type mismatch (type 'Symbol') in equality or conditional
       -- 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".

635    resetting strong parent of type 'Symbol', old parent == type
       'Symbol'  -- 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.

636    ptr to strong type 'Name' versus another type  -- 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.

637    Expected index type 'Symbol' for strong type 'Symbol'  -- 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.

638    Strong type mismatch for type 'Name' in relational  -- A
       relational operation ( >=  <=  >  < ) violates a Strong type
       check as requested by a -strong(J... option.  This message would
       have been suppressed using flags "Jr".

639    Strong type mismatch for type 'Name' in binary operation  -- 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".

640    Expected strong type 'Name' in Boolean context  -- A Boolean
       context expected a type specified by a -strong(B... option.

641    Converting enum to int  -- 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.

642    Format char 'Char' not supported by wsprintf  -- 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.

643    Loss of precision in pointer cast  -- 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.

644    Variable 'Symbol' (Location) may not have been initialized  -- An
       auto variable was not necessarily assigned a value before use.

645    Symbol 'Symbol' (Location) may not have been initialized  -- 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.

646    case/default within Kind loop; may have been misplaced  -- A case
       or default statement was found within a for, do, or while loop.
       Was this intentional?  At the very least, this reflects poor
       programming style.

647    Suspicious truncation  -- 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.

       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.

648    Overflow in computing constant for operation: String  --
       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 */

649    Sign fill during constant shift  -- 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.

650    Constant out of range for operator String  -- In a comparison
       operator or equality test (or implied equality test as for a case
       statement), a constant operand 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.

651    Potentially confusing initializer  -- 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.

652    #define of symbol 'Symbol' declared previously at Location  -- 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.

653    Possible loss of fraction  -- 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.

654    Option String obsolete; use -width(W,I)  -- 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).

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

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

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

658    Anonymous union assumed (use flag +fan)  -- 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++.

659    Nothing follows '}' on line within struct/union/enum declaration
       -- 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.

660    Option 'String' requests removing an extent that is not on the
       list  -- 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.

661    possible access of out-of-bounds pointer ('Integer' beyond end of
       data) by operator 'String'  -- 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.

662    possible creation of out-of-bounds pointer ('Integer' beyond end
       of data) by operator 'String'  -- 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.

663    Suspicious array to pointer conversion  -- 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.

664    Left side of logical OR (||) or logical AND (&&) does not return
       -- An exiting function was found on the left hand side of an
       operator implying that the right hand side would never be
       executed.  For example:
       
               if( (exit(0),n == 0) || n > 2 ) ...

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

665    Unparenthesized parameter Integer in macro 'Symbol' is passed an
       expression  -- An expression was passed to a macro parameter that
       was not parenthesized.  For example:
       
               #define mult(a,b) (a*b)
               ...   mult( 100, 4 + 10 )

       Here the programmer is beguiled into thinking that the 4+10 is
       taken as a quantity to be multiplied by 100 but instead results
       in: 100*4+10 which is quite 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( ... )

666    Expression with side effects passed to repeated parameter Integer
       of macro 'Symbol'  -- 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.

667    Inconsistent use of qualifiers for symbol 'Symbol' (type 'Type'
       vs. 'Type') conflicts with Location  -- 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.

668    Possibly passing a null pointer to function 'Symbol', Context
       Reference  -- 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.

669    Possible data overrun for function 'Symbol', argument Integer
       exceeds argument Integer Reference  -- 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.

670    Possible access beyond array for function 'Symbol', argument
       Integer exceeds Integer Reference  -- 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.

671    Possibly passing to function 'Symbol' a negative value (Integer),
       Context Reference  -- 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.

672    Possible memory leak in assignment to pointer 'Symbol'  -- 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.

673    Possibly inappropriate deallocation (Name1) for 'Name2' data.  --
       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.

674    Returning address of auto through variable 'Symbol'.  -- The
       value held by a pointer variable contains the address of an auto
       variable.  It is normally incorrect to return the address of an
       item on the stack because the portion of the stack allocated to
       the returning function is subject to being obliterated after
       return.

675    No prior semantics associated with 'Name' in option 'String'  --
       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.

676    Possibly negative subscript (Integer) in operator 'String'  -- 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.

677    sizeof used within preprocessor statement.  -- Whereas the use of
       sizeof during preprocessing is supported by a number of compilers
       it is not a part of the ANSI C or C++ standard.

678    Member 'Symbol' field length (Integer) too small for enum
       precision (Integer)  -- 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.

679    Suspicious Truncation in arithmetic expression combining with
       pointer  -- 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);

680    Suspicious Truncation in arithmetic expression converted to
       pointer  -- An arithmetic expression was cast to pointer.
       Moreover, the size of the pointer is greater than the size of the
       expression.  In computing the expression, any 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.

681    Loop is not entered  -- The controlling expression for a loop
       (either the expression within a while clause or the second
       expression within a for clause) evaluates initially to 0 and so
       it appears as though the loop is never entered.

682    sizeof applied to a parameter 'Symbol' whose type is a sized
       array  -- 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.

683    function 'Symbol' #define'd  -- 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.

684    Passing address of auto variable 'Symbol' into caller space  --
       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.

685    Relational operator 'String,' always evaluates to 'String'  --
       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.

686    Option 'String' is suspicious because of 'Name'  -- 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'.

687    Suspicious use of comma operator  -- A comma operator appeared
       unbraced and unparenthesized in a statement following an if,
       else, while or for clause.  For example:
       
                 if( n > 0 ) n = 1,
                 n = 2;
       
       Thus the comma could be mistaken for a semi-colon and hence be
       the source of subtle bugs.

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

688    Cast used within a preprocessor conditional statement  -- 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.

689    Apparent end of comment ignored  -- The pair of characters '*/'
       was found not within a comment.  As an example:
       
                 void f( void*/*comment*/ );
       
       This is taken to be the equivalent of:
       
                 void f( void*  );
       
       That is, an implied blank is inserted between the '*' and the
       '/'.  To avoid this message simply place an explicit blank
       between the two characters.

690    Possible access of pointer pointing Integer bytes past nul
       character by operator 'String'  -- 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

691    Suspicious use of backslash  -- The backslash character has been
       used in a way that may produce unexpected results.  Typically
       this would occur within a macro such as:
       
                 #define A b \ // comment
       
       The coder might be thinking that the macro 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 */ \
       
692    Decimal character 'Char' follows octal escape sequence 'String'
       -- A String was found that contains an '8' or '9' after an octal
       escape sequence with no more than two octal digits, e.g.
       
                 "\079"
       
       contains two characters: Octal seven (ASCII BEL) followed by '9'.
       The casual reader of the code (and perhaps even the programmer)
       could be fooled into thinking this is a single character.  If
       this is what the programmer intended he can also render this as
       
                 "\07" "9"
       
       so that there can be no misunderstanding.

       On the other hand,
       
                "\1238"
       
       will not raise a message because it is assumed that the
       programmer knows that octal escape sequences cannot exceed four
       characters (including the initial backslash).

693    Hexadecimal digit 'Char' immediately after 'String' is suspicious
       in string literal.  -- 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.

694    The type of constant 'String' (precision Integer) is dialect
       dependent  -- 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.

695    Inline function 'Symbol' defined without a storage-class
       specifier ('static' recommended)  -- 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'.

696    Variable 'Symbol' has value 'String' that is out of range for
       operator 'String'  -- 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).

697    Quasi-boolean values should be equality-compared only with 0  --
       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.

698    Casual use of realloc can create a memory leak  -- A statement of
       the form:
       
                 v = realloc( v, ... );
       
       has been detected.  Note the repeated use of the same variable.
       The problem is that realloc can fail to allocate the necessary
       storage.  In so doing it will return NULL.  But then the original
       value of v is overwritten resulting in a memory leak.



19.5  C Informational Messages


701    Shift left of signed quantity (int)  -- Shifts are normally
       accomplished on unsigned operands.

702    Shift right of signed quantity (int)  -- Shifts are normally
       accomplished on unsigned operands.  Shifting an int right is
       machine dependent (sign fill vs. zero fill).

703    Shift left of signed quantity (long)  -- Shifts are normally
       accomplished on unsigned operands.

704    Shift right of signed quantity (long)  -- Shifts are normally
       accomplished on unsigned operands.  Shifting a long right is
       machine dependent (sign fill vs. zero fill).

705    Argument no. Integer nominally inconsistent with format  -- 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.

706    (arg. no. Integer) indirect object inconsistent with format  --
       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.

707    Mixing narrow and wide string literals in concatenation.  -- The
       following is an example of a mixing of narrow and wide string
       literals.
       
             const wchar_t *s = "abc" L"def";
       
       The concatenation of narrow and wide string literals results in
       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.

708    union initialization  -- 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.

712    Loss of precision (Context) (Type to Type)  -- 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.

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

714    Symbol 'Symbol' (Location) not referenced  -- The named external
       variable or external function was defined but not referenced.
       This message is suppressed for unit checkout (-u option).

715    Symbol 'Symbol' (Location) not referenced  -- The named formal
       parameter was not referenced.

716    while(1) ...  -- 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(;;).

717    do ... while(0)  -- 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

718    Symbol 'Symbol' undeclared, assumed to return int  -- 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.

719    Too many arguments for format (Integer too many)  -- 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.

720    Boolean test of assignment  -- 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 ==.

721    Suspicious use of ;  -- 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.

722    Suspicious use of ;  -- 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.

723    Suspicious use of =  -- 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?

725    Expected positive indentation from Location  -- 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.

726    Extraneous comma ignored  -- A comma followed by a right-brace
       within an enumeration is not a valid ANSI construct.  The comma
       is ignored.

727    Symbol 'Symbol' (Location) not explicitly initialized  -- 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.

728    Symbol 'Symbol' (Location) not explicitly initialized  -- The
       named intra-module variable (static variable with file scope) was
       not explicitly initialized.  See the comments on message 727 for
       more details.

729    Symbol 'Symbol' (Location) not explicitly initialized  -- The
       named inter-module variable (external variable) was not
       explicitly initialized.  See the comments on message 727 for more
       details.  This message is suppressed for unit checkout (-u).

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

731    Boolean argument to equal/not equal  -- 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.

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

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

       where u is unsigned and n is not, warrants a message only for the
       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.

733    Assigning address of auto variable 'Symbol' to outer scope symbol
       'Symbol'  -- 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.

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

               ch  =  n;

       will trigger this message whereas:

               ch  =  n & 1;

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

               ch  =  (char) n;

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

               ch = ch << 2
               ch = ch * ch

       where, for example, ch is an unsigned char.  These can be
       suppressed by using the flag +fpm (precision of an operator is
       bound by the maximum of its operands).

735    Loss of precision (Context) (Integer bits to Integer bits)  -- 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.

736    Loss of precision (Context) (Integer bits to Integer bits)  -- An
       assignment (or implied assignment, see Context) is being made to
       a float from a value or combination of values that appear to have
       higher precision than a float.  You may suppress this message by
       using a cast.  The number of bits includes the sign bit.

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

                u  &  ~0xFF 

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

       This mixed mode operation could also draw Warnings 573 or 574
       depending upon 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.

738    Symbol 'Symbol' (Location) not explicitly initialized  -- 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.

739    Trigraph Sequence 'String' in literal (Quiet Change)  -- 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.

740    Unusual pointer cast (incompatible indirect types)  -- 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.

741    Unusual pointer cast (function qualification)  -- 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 *.

742    Multiple character constant  -- A character constant was found
       that contained multiple characters, e.g., 'ab'.  This is legal C
       but the numeric value of the constant is implementation 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.

743    Negative character constant  -- 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.

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

       This message is not given if the control expression is an
       enumerated type.  In this case, all enumerated constants are
       expected to be represented by case statements, else 787 will be
       issued.

745    function 'Name' has no explicit type or class, int assumed  -- A
       function declaration or definition contained no explicit type.
       Was this deliberate?

746    call to function 'Name' not made in the presence of a prototype
       -- A call to a function is not made in the presence of a
       prototype.  This does not mean that PC-lint/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.

747    Significant prototype coercion (Context) Type to Type  -- 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.

748    Symbol 'Symbol' (Location) is a register variable used with
       setjmp  -- 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.

749    local enumeration constant 'Symbol' (Location) not referenced  --
       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.

750    local macro 'Symbol' (Location) not referenced  -- 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.

751    local typedef 'Symbol' (Location) not referenced  -- 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.

752    local declarator 'Symbol' (Location) not referenced  -- 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.

753    local struct, union or enum tag 'Symbol' (Location) not
       referenced  -- 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.

754    local structure member 'Symbol' (Location) not referenced  -- 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.

755    global macro 'Symbol' (Location) not referenced  -- 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).

756    global typedef 'Symbol' (Location) not referenced  -- 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).

757    global declarator 'Symbol' (Location) not referenced  -- 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).

758    global struct, union or enum tag 'Symbol' (Location) not
       referenced  -- 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).

759    header declaration for symbol 'Symbol' (Location) could be moved
       from header to module  -- 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.

760    Redundant macro 'Symbol' defined identically at Location  -- The
       given macro was defined earlier (location given) in the same way
       and is hence redundant.

761    Redundant typedef 'Symbol' previously declared at Location  -- A
       typedef symbol has been typedefed earlier at the given location.
       Although the declarations are consistent you should probably
       remove the second.

762    Redundantly declared symbol 'Symbol' previously declared at
       Location  -- 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.

763    Redundant declaration for symbol 'Symbol' previously declared at
       Location  -- A tag for a struct, union or enum was defined twice
       in the same module (consistently).  The second one can be
       removed.

764    switch statement does not have a case  -- 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.

765    external 'Symbol' (Location) could be made static  -- 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.

766    Header file FileName not used in module String  -- 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.

767    macro 'Symbol' was defined differently in another module
       (Location)  -- Two macros processed in two different modules had
       inconsistent definitions.

768    global struct member 'Symbol' (Location) not referenced  -- 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.

769    global enumeration constant 'Symbol' (Location) not referenced
       -- 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.

770    tag 'Symbol' defined identically at Location  -- 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.

771    Symbol 'Symbol' (Location) conceivably not initialized  -- 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.

772    Symbol 'Symbol' (Location) conceivably not initialized  -- 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."

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

               #define A  B + 1

       may be used later in the context:

               f( A * 2 );

       with the surprising result that B+2 gets passed to f and not the
       (B+1)*2 corrective action is to 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]

774    Boolean within 'String' always evaluates to [True/False]  -- 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.

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

776    Possible truncation of addition  -- An int expression (signed or
       unsigned) involving addition or subtraction is converted to long
       implicitly or explicitly.  Moreover, the precision of a long is
       greater than that of int.  If an 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.

777    Testing float's for equality  -- 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.

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

779    String constant in comparison operator: Operator  -- A string
       constant appeared as an argument to a comparison operator.  For
       example:

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

       This is usually an error.  Did the programmer intend to use
       strcmp?  It certainly looks suspicious. At the very least, any
       such comparison is bound to be machine-dependent.  If you cast
       the string constant, the message is suppressed.

780    Vacuous array element  -- 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.

782    Line exceeds Integer characters  -- 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.

783    Line does not end with new-line  -- 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.

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

               char a[3] = "abc";

       would evoke such a message.  This may not be an error since the
       easiest way to do this initialization is in the manner indicated.
       It is more convenient than:
               char a[3] = { 'a', 'b', 'c' };

       On the other hand, if it really is an error it may be especially
       difficult to find.

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

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

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

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

787    enum constant 'Symbol' not used within switch  -- A switch
       expression is an enumerated type and at least one of the
       enumerated constants was not present as a case label.  Moreover,
       no default case was provided.

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

789    Assigning address of auto variable 'Symbol' to static  -- The
       address of an auto variable (Symbol) is being assigned to a
       static variable.  This is dangerous because the static variable
       will persist after return from the function in which the auto is
       declared but the auto will be, in theory, gone.  This can prove
       to be among the hardest bugs to find.  If you have one of these,
       make certain there is no error and use -esym to suppress the
       message for a particular variable.

790    Suspicious truncation, integral to float.  -- 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.

791    unusual option sequence  -- A temporary message suppression
       option (one having the form:  !e...) followed a regular option.
       Was this intended?

792    void cast of void expression  -- A void expression has been cast
       to void.  Was this intended?

793    ANSI limit of String 'String' 'Name' exceeded -- processing is
       unaffected  -- 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)"

794    Conceivable use of null pointer 'Symbol' in [left/right] argument
       to operator 'String' Reference  -- 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.

795    Conceivable division by 0  -- In a division or modulus operation
       the division is deduced to be conceivably 0.

796    Conceivable access of out-of-bounds pointer ('Integer' beyond end
       of data) by operator 'String'  -- 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.

797    Conceivable creation of out-of-bounds pointer ('Integer' beyond
       end of data) by operator 'String'  -- 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'.

798    Redundant character 'Char'  -- 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.

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

801    Use of goto is deprecated  -- 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.

802    Conceivably passing a null pointer to function 'Symbol', Context
       Reference  -- 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.

803    Conceivable data overrun for function 'Symbol', argument Integer
       exceeds argument Integer Reference  -- 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.

804    Conceivable access beyond array for function 'Symbol', argument
       Integer exceeds Integer Reference  -- 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.

805    Expected L"..." to initialize wide char string  -- 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.

806    Small bit field is signed rather than unsigned  -- 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 */
               ...

807    Conceivably passing to function 'Symbol' a negative value
       (Integer), Context Reference  -- 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.

808    No explicit type given symbol 'Sybmol', assumed int  -- 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.

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

810    Arithmetic modification of custodial pointer 'Symbol'  --
       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.

811    Possible deallocation of pointer alias  -- 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.

812    static variable 'Symbol' has size 'Integer'  -- 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").

813    auto variable 'Symbol' in function 'Symbol' has size 'Integer'
       -- 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").

814    useless declaration  -- A tagless struct was declared without a
       declarator.  For example:
       
             struct { int n; };
       
       Such a declaration cannot very well be used.

815    Arithmetic modification of unsaved pointer  -- 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.

816    Non-ANSI format specification  -- 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.

817    Conceivably negative subscript (Integer) in operator 'String'  --
       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.

818    Pointer parameter 'Symbol' (Location) could be declared ptr to
       const  -- 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.

820    Boolean test of a parenthesized assignment  -- 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.

821    Right hand side of assignment not parenthesized  -- 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) );

825    control flows into case/default without -fallthrough comment  --
       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.

826    Suspicious pointer-to-pointer conversion (area too small)  -- 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; }

827    Loop not reachable  -- 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.

828    Semantics of function 'Name' copied to function 'Name'  -- 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.

829    A +headerwarn option was previously issued for header 'Symbol  --
       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.

830    Location cited in prior message  -- 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.

831    Reference cited in prior message  -- 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.

832    Parameter 'Symbol' not explicitly declared, int assumed  -- 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.

833    Symbol 'Symbol' is typed differently (String) in another module,
       Location,  -- 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.

834    Operator 'Name' followed by operator 'Name' is confusing.  Use
       parentheses.  -- 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.

835    A zero has been given as [left/right] argument to operator 'Name'
       -- 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.

836    Conceivable access of pointer pointing Integer bytes past nul
       character by operator 'String'  -- 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.

838    Previously assigned value to variable 'Symbol' has not been used
       -- 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.

839    Storage class of symbol 'Symbol' assumed static (Location)  -- 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.

840    Use of nul character in a string literal  -- 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.

843    Variable 'Symbol' (Location) could be declared as const  -- 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.

844    Pointer variable 'Symbol' (Location) could be declared as
       pointing to const  -- 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.

845    The [left/right] argument to operator 'Name' is certain to be 0
       -- 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;
       
846    Signedness of bit-field is implementation defined  -- 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.

847    Thread 'Symbol' has unprotected call to thread unsafe function
       'Symbol'  -- 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.

848    Worst case function for stack usage: String  -- 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.

849    Symbol 'Symbol' has same enumerator value 'String' as enumerator
       'Symbol'  -- 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.

850    for loop index variable 'Symbol' whose type category is 'String'
       modified in body of the for loop that began at 'String'  -- 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.

864    Expression involving variable 'Symbol' possibly depends on order
       of evaluation  -- 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).

866    Unusual use of 'String' in argument to sizeof  -- 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().
       

867    Unrecognized pragma 'Name' will be ignored  -- 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.



19.6  C Elective Notes

900    Successful completion, 'Integer' messages produced  -- 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.

904    Return statement before end of function 'Symbol'  -- 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.

905    Non-literal format specifier used (with arguments)  -- 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

909    Implicit conversion from Type to bool  -- 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.

910    Implicit conversion (Context) from 0 to pointer  -- 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.

911    Implicit expression promotion from Type to Type  -- 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.

912    Implicit binary conversion from Type to Type  -- 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.

913    Implicit adjustment of expected argument type from Type to Type
       -- 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.

914    Implicit adjustment of function return value from Type to Type
       -- Notes whenever the function return value is implicitly
       adjusted.  This message is given only for functions returning
       arrays.

915    Implicit conversion (Context) Type to Type  -- Notes whenever an
       assignment, initialization or return implies an arithmetic
       conversion (Context specifies which).

916    Implicit pointer assignment conversion (Context)  -- Notes
       whenever an assignment, initialization or return implies an
       implicit pointer conversion (Context specifies which).

917    Prototype coercion (Context) Type to Type  -- 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.

918    Prototype coercion (Context) of pointers  -- 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.

919    Implicit conversion (Context) Type to Type  -- A lower precision
       quantity was assigned to a higher precision variable as when an
       int is assigned to a double.

920    Cast from Type to void  -- A cast is being made from the given
       type to void.

921    Cast from Type to Type  -- A cast is being made from one integral
       type to another.

922    Cast from Type to Type  -- A cast is being made to or from one of
       the floating types (float, double, long double).

923    Cast from Type to Type  -- A cast is being made either from a
       pointer to a non-pointer or from a non-pointer to a pointer.

924    Cast from Type to Type  -- 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.

925    Cast from pointer to pointer  -- 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.

926    Cast from pointer to pointer  -- 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.

927    Cast from pointer to pointer  -- 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.

928    Cast from pointer to pointer  -- A cast is being made from a
       non-char pointer to a char pointer.  This is generally considered
       to be a 'safe' conversion.

929    Cast from pointer to pointer  -- 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.

930    Cast from Type to Type  -- A cast is being made to or from an
       enumeration type.

931    Both sides have side effects  -- 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.

932    Passing near pointer to library function '(Symbol)' (Context)  --
       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.

933    Passing near pointer to far function (Context)  -- 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.

934    Taking address of near auto variable 'Symbol' (Context)  -- 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.

935    int within struct  -- 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.

936    old-style function definition for function 'Symbol'  -- 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.

937    old-style function declaration for function 'Symbol'  -- An
       "old-style" function declaration is one which does not have type
       information for its arguments.

938    parameter 'Symbol' not explicitly declared  -- 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.

939    return type defaults to int for function 'Symbol'  -- 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.

940    omitted braces within an initializer  -- 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.

941    Result 0 due to operand(s) equaling 0 in operation 'String'  --
       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.

942    Possibly truncated addition promoted to float  -- 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.

943    Too few initializers for aggregate 'Symbol'  -- 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.

944    [left/right/] argument for operator 'String' always evaluates to
       [True/False]  -- 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.

945    Undefined struct used with extern  -- 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.

946    Relational or subtract operator applied to pointers  -- 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.

947    Subtract operator applied to pointers  -- 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.

948    Operator 'String' always evaluates to [True/False]  -- 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.

950    Non-ANSI reserved word or construct: 'Symbol'  -- 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).

951    Pointer to incomplete type 'Symbol' employed in operation  -- 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.

952    Parameter 'Symbol' (Location) could be declared const  -- 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.

953    Variable 'Symbol' (Location) could be declared as const  -- 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.

954    Pointer variable 'Symbol' (Location) could be declared as
       pointing to a const  -- 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.

955    Parameter name missing from prototype for function 'Symbol'  --
       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.

956    Non const, non volatile static or external variable 'Symbol'  --
       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.

957    Function 'Symbol' defined without a prototype in scope  -- 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.

958    Padding of Integer byte(s) is required to align member on Integer
       byte boundary  -- 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.

959    Nominal struct size (Integer bytes) is not an even multiple of
       the maximum member alignment (Integer bytes)  -- 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.

960    Violates MISRA Year Required Rule Name, String  -- 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.

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

       The list of advisory checks made for both MISRA 1998 and 2004
       are:

       (Rule 47/12.1) Dependence placed on C's operator precedence 
       (Rule 87/19.1) Only preprocessor statements and comments before '#include'.
       (Rule 93/19.7) Use of function-like macros is discouraged.
       (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.

962    Macro 'Symbol' defined identically at another location (Location)
       -- 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.

963    Qualifier const or volatile follows/precedes a type; use
       -fqb/+fqb to reverse the test  -- 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.

964    Header file FileName not directly used in module String  -- 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.

966    Indirectly included header file 'FileName' not used by module
       'String'  -- 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.

967    Header file 'FileName' does not have a standard include guard  --
       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.

970    Use of modifier or type 'Name' outside of a typedef  -- 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)

971    Use of 'char' without 'signed' or 'unsigned'  -- 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.

973    Unary operator in macro 'Symbol' not parenthesized  -- 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.

974    Worst case function for stack usage: String  -- 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.

975    Unrecognized pragma 'Name' will be ignored  -- 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.



19.7  C++ Syntax Errors
1001   Scope 'Name' must be a struct or class name  -- In an expression
       of the form X::Y,  X must be a class name.  [11, §10.4]

1002   'this' must be used in class member function  -- 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]

1003   'this' may not be used in a static member function  -- A static
       member function receives no this pointer.  [11, §9.4]

1004   Expected a pointer to member after .* or ->*  -- The .* and ->*
       operators require pointer to members on the right hand side.
       [11, §5.5]

1005   Destructor declaration requires class  -- 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]

1006   Language feature 'String' not supported  -- The indicated
       feature, while not supported in the current version, will
       hopefully be supported in future versions of the product.

1007   Pure specifier for function 'Symbol' requires a virtual function
       -- 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]

1008   Expected '0' to follow '=', text ignored  -- 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]

1009   operator String not redefinable  -- The cited operator, one of
       '.*',  '?', '::' or  '.', may not be overloaded.  [11, §13.4]

1010   Expected a type or an operator  -- Following the keyword operator
       the parser expected either an operator (including new, delete,
       (), [], comma) or a type.  [11, §13.4 and §12.3.2]

1011   Conversion Type Name too long  -- An upper limit of 50 characters
       has been reached on a conversion type name.

1012   Type not needed before 'operator type'  -- 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]

1013   Symbol 'Name' not a member of class 'Name'  -- 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]

1014   Explicit storage class not needed for member function 'Symbol'
       -- 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.

1015   Symbol 'Name' not found in class  -- 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]

1016   Symbol 'Symbol' is supposed to denote a class  -- 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]

1017   conflicting access-specifier 'String'  -- Two different access
       specifiers were given in a simple base-specifier.  [11, §10]

1018   Expected a type after 'new'  -- In an expression involving new, a
       type is expected after possibly processing a placement.  None was
       found.  [11, §5.3.3]

1019   Could not find match for function 'Symbol(String)'  -- 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]

1020   template specialization for 'Symbol' declared without a
       'template<>' prefix  -- A class template specialization is
       generally preceded by a 'template<>' clause as in:
       
                 template< class T > class A { };       // a template
                 template<> class A<int> { };           // a specialization
       
       If the 'template<>' is omitted, you will get this message but it
       will still be interpreted as a specialization.  Before the
       standardization of template syntax was completed, a template
       specialization did not require this clause and its absence is
       still permitted by some compilers.

1022   Function: 'String' must be a class member  -- 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]

1023   Call String(String) is ambiguous; candidates: String  -- A call
       to an overloaded function or operator is ambiguous.  The
       candidates of choice are provided in the message.  [11, §13.2]

1024   No function has same argument count as 'Name'  -- 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]

1025   No function matches invocation 'Name' on arg no. Integer  -- 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]

1026   Undominated function 'String' does not dominate 'String' on call
       to 'String'  -- 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]

1027   Non-consecutive default arguments in function 'String', assumed 0
       -- Default arguments need to be consecutive.  For example

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

       is illegal.  [11, §8.2.6]

1028   Last argument not default in first instance of function 'String',
       assumed 0  -- 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]

1029   Default argument repeated in function 'String'  -- A default
       value for a given argument for a given function should only be
       given once.  [11, §8.2.6]

1030   Not all arguments after arg no. Integer are default in function
       'String'  -- 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]

1031   Local variable 'Symbol' used in default argument expression  --
       Default values for arguments may not use local variables.  [11,
       §8.2.6]

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

1033   Static member functions cannot be virtual  -- You may not declare
       a static member function virtual.  [11, §10.2]

1034   Static member 'Symbol' is global and cannot be redefined  -- 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]

1035   Non-static member 'Symbol' cannot initialize a default argument
       -- A default argument cannot be initialized from a class member
       unless an instantiation of the class is provided.  [11, §8.2.6]

1036   ambiguous reference to constructor; candidates: 'String'  --
       There is more than one constructor that can be used to make a
       desired conversion.  [11, §12.3.2]

1037   ambiguous reference to conversion function; candidates: 'String'
       -- There is more than one conversion function (of the form
       operator type () ) that will perform a desired conversion.  [11,
       §12.3.2]

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

1039   Symbol 'Symbol' is not a member of class 'String'  -- In a
       declaration for the symbol X::Y, Y was not previously established
       as a member of X.  [11, §10.4]

1040   Symbol 'Symbol' is not a legal declaration within class 'String'
       -- 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.

1041   Can't declare 'String', assumed 'operator String'  -- 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]

1042   At least one class-like operand is required with Name  -- In
       defining (or declaring) an operator you must have at least one
       class as an operand.  [11, §13.4]

1043   Attempting to 'delete' a non-pointer  -- 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]

1046   member 'Symbol', referenced in a static function, requires an
       object  -- The Symbol is a non-static member of a class and hence
       requires a class instantiation.  None is in sight.  [10, §9.4]

1047   a template declaration must be made at file scope  -- A template
       declaration may not appear within a function or within a class.
       [10, §14.1]

1048   expected a constant expression  -- 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]

1049   Too many template arguments  -- There are more arguments in the
       template class-name than there were parameters in the original
       template declaration.  [10, §14.5]

1050   expected a template argument list '<...>' for template 'Symbol'
       -- The name of a class template identified by Symbol was used
       without specifying a template argument list.  [10, §14.5]

1051   Symbol 'Name' is both a function and a variable  -- 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]

1052   a type was expected, 'class' assumed  -- 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]

1053   'String' cannot be distinguished from 'String'  -- 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]

1054   template variable declaration expects a type, int assumed  -- 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]

1055   Symbol 'Symbol' undeclared, assumed to return int  -- 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]

1056   assignment from void * is not allowed in C++  -- 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]

1057   member 'Symbol' cannot be used  without an object  -- The
       indicated member referenced via scope operator cannot be used in
       the absence of this pointer.  [11, §5.2.4]

1058   Initializing a non-const reference 'Symbol' with a non-lvalue  --
       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(...);

1059   Can't convert from 'Type' to 'Type'  -- 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]

1060   String member 'Symbol' is not accessible to non-member non-friend
       functions  -- 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]

1061   String member 'Symbol' is not accessible through non-public
       inheritance  -- 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]

1062   template must be either a class or a function  -- Following
       template < arglist > the parser expects to find either the token
       class or a function declaration or definition.  [10, §14.5]

1063   Argument to copy constructor for class 'Symbol' should be a
       reference  -- A constructor for a class closely resembles a copy
       constructor.  A copy constructor for class X is typically
       declared as:

               X( const X &)

       If you leave 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]

1064   Template parameter list for template 'Symbol' inconsistent with
       Location  -- The template parameter list for a template function
       declaration or definition is inconsistent with that of a prior
       declaration or definition.  [10, §14.5]

1065   Symbol 'Symbol' not declared as "C" conflicts with Location  -- 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]

1066   Symbol 'Symbol' declared as "C" conflicts with Location  -- 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]

1067   invalid prototype for function 'Symbol'  -- 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].

1068   Symbol 'Symbol' can not be overloaded  -- 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].

1069   Symbol 'Name' is not a base class of class 'Name'  -- 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.

1070   No scope in which to find symbol 'Name'  -- This could arise in
       an expression of the form X::Y where X does not represent a valid
       scope.

1071   Constructors and destructors can not have return type  --
       Constructors and destructors may not be declared with a return
       type, not even void.  See ARM Section 12.1 and 12.4.

1072   Reference variable 'Symbol' must be initialized  -- A reference
       variable must have an initializer at the point of declaration.

1073   Insufficient number of template parameters for 'Symbol'; 'String'
       assumed  -- A (class) template instantiation did not have a
       sufficient number of parameters.  String indicates what the
       missing argument is presumed to be.

1074   Expected a namespace identifier  -- In a declaration of the form:
       
               namespace name = scoped-identifier

       the scoped-identifier must identify a namespace.

1075   Ambiguous reference to symbol 'Symbol' and symbol 'Symbol'  --
       Two namespaces contain the same name.  A reference to such a name
       could not be disambiguated.  You must fully qualify this name in
       order in indicate which name is intended.

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

1077   Could not evaluate default template parameter 'String'  -- 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.

1078   class 'Symbol' should not have itself as a base class  -- 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.

1079   Could not find '>' or ',' to terminate template parameter at
       Location  -- 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.

1080   Definition for class 'Name' is not in scope  -- 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

1081   Object parameter does not contain the address of a variable  --
       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
       
1082   Object parameter for a reference type should be an external
       symbol  -- 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.

1083   Ambiguous conversion between 2nd and 3rd operands of conditional
       operator  -- 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.

1084   Ambiguous use of template-id for instantiation of 'Type'  -- 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)
       

1085   Invalid definition of 'String'  -- 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.

1086   Compound literals may only be used in C99 programs  -- 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.

1087   Previous declaration of 'Name' (Location) is incompatible with
       'Name' (Location) which was introduced by the current
       using-declaration  -- 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.
       
1088   A using-declaration must name a qualified-id  -- This error is
       issued when a using-declaration references a name without the ::
       scope resolution operator; e.g.:
       
                 class A { protected: int n; };
                 class B : public A {
                 public:
                     using n; // Error 1088: should be 'using A::n;'
                 };
       
       See Section 14. Added Bibliography, [34], 7.3.3 namespace.udecl.

1089   A using-declaration must not name a namespace  -- 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.

1090   A using-declaration must not name a template-id  -- 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.

1091   'Name' is not a base class of 'Name'  -- 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.

1092   A using-declaration that names a class member must be a
       member-declaration  -- 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.

1093   A pure specifier was given for function 'Symbol' which was not
       declared virtual  -- A pure specifier ("= 0") should not be
       placed on a function unless the function had been declared
       "virtual".

1094   Could not find ')' or ',' to terminate default function argument
       at Location  -- 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.

1095   Effective type 'Type' of non-type template parameter #Integer
       (corresponding to argument expression 'String') depends on an
       unspecialized parameter of this partial specialization  -- 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.

1096   A target ctor must be the only mem-initializer in the
       mem-initializer-list of a delegating ctor  -- 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
                 {}
             };
       

1097   Delegating ctor delegates directly to itself, causing infinite
       recursion  -- Example:
       
         struct A
             {
             int n;
             A(int x) : A(x){} // Error 1097
             };
       

1098   Function template specialization 'Symbol' does not match any
       function template  -- This message is issued for a declaration
       where the user apparently intended to name a specialization of a
       function template (e.g., in an explicit specialization, an
       explicit instantiation or a friend declaration of
       specialization), but no previously-declared function template is
       matched.  Example:
       
             template<class T> void f( const T& ); // #1

             struct A{};
             template<> void f( const A& ); // Ok
             // (A is the deduced argument to T.)

             struct B{};
             template<> void f( const B ); // Error 1097.
             // (A template argument cannot be deduced for T.)
       

1099   Ambiguous function template specialization 'Symbol'  -- 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.

1100   Declaration of 'Symbol' does not declare an explicit
       specialization, explicit instantiation or friend  -- 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'---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
       

1101   Type of variable 'Symbol' cannot be deduced from its initializer
       -- Example:
       
             int f(void);
             int f(char*);
             auto n = f; // Error
       
       In terms of deduction, this is equivalent to:
       
             int f(void);
             int f(char*);
             template<class T> void g( const T& );
             void h( void )
                 {
                 g( f ); // Error
                 }
       
       Here,  'f' refers to multiple overloaded functions, so it is an
       ambiguous reference and T cannot be deduced.  (Code like this
       could still be well-formed however, e.g. if g is overloaded with
       a non-template function whose parameter type is 'ptr-to-function
       returning int taking (char*)'.)

1102   auto type deduced inconsistently: 'Type' for 'Symbol' but 'Type'
       for 'Symbol'  -- 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
       

1103   Type 'Type' is not allowed as an enum-base  -- 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
       

1104   A reference to enumeration 'Symbol' should not use 'String'  --
       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'
       

1105   Use of ref qualification of 'Symbol' inconsistent with overloaded
       function 'Symbol' (Location)"  -- 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
                 };
       

1106   Initializing value 'String' of enumerator 'Name' cannot be
       represented by the enumeration's underlying type 'Type'  -- 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.

1107   Mixing two different kinds of string literals  -- 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
             }
       

1110   Cycle detected: explicit application of 'Name'::operator-> causes
       infinite implicit applications of the same operator  -- 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
       

1111   ISO C++ requires an explicit specialization/instantiation to
       appear at namespace scope  -- 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.



19.8  Additional Internal Errors
12XX   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.



19.9  C++ Warning Messages
1401   member 'Symbol' (Location) not initialized by constructor  -- The
       indicated member symbol was not initialized by a constructor.
       Was this an oversight?

1402   member 'Symbol' (Location) not initialized  -- 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.

1403   member 'Symbol' (Location) not initialized  -- 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.

1404   deleting an object of type 'Symbol' before type is defined  --
       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.

1405   Header typeinfo must be included before typeid is used  --
       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.

1411   Member with different signature hides virtual member 'Symbol'
       (Location)  -- 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.

1412   Reference member 'Symbol' is not initialized  -- 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.

1413   function 'Symbol' is returning a temporary via a reference  -- 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.

1414   Assigning address of auto variable 'Symbol' to member of this  --
       The address of an auto variable was taken and assigned to a this
       member in a member function.  For example:
       
                 struct A
                     {
                     char *x;
                     void f()
                         {
                         char y[10];
                         x = y;          // warning 1414
                         }
                     };
       
       Here the address of y is being passed to member x but this is
       dangerous (if not ridiculous) since when the function returns,
       the storage allocated for y is deallocated and the pointer could
       very easily harm something.

1415   Pointer to non-POD class 'Name' passed to function 'Symbol'
       (Context)  -- 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

1416   An uninitialized reference 'Symbol' is being used to initialize
       reference 'Symbol'  -- 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.

1417   reference member 'Symbol' not initialized by constructor
       initializer list  -- 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) { /* ... */ }
                     };
       
1501   data member 'Symbol' has zero size  -- A data member had zero
       size.  It could be an array of zero length or a class with no
       data members.  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,...).

1502   defined object 'Symbol' has no nonstatic data members  -- A
       variable (Symbol) is being instantiated that belongs to a class
       that contains no data members (either directly or indirectly
       through inheritance).  [11, §9]

1503   a tagged union is not anonymous  -- A tagged union without a
       declarator appeared within a struct/union declaration.  An
       anonymous union requires no tag.  [11, §9.5]

1504   useless struct declaration  -- An untagged struct declaration
       appeared within a struct/union and has no declarator.  It is not
       treated like an anonymous union.  Was this intended?

1505   no access specifier provided, 'String' assumed  -- 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]

1506   Call to virtual function 'Symbol' within a constructor or
       destructor  -- 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]

1507   attempting to 'delete' an array  -- 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]

1509   base class destructor for class 'Name' is not virtual  -- 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]

1510   base class 'Name' has no destructor  -- 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]

1511   Member hides non-virtual member 'Symbol' (Location)  -- 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.

1512   destructor for base class 'Symbol' (Location) is not virtual  --
       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]

1513   storage class ignored  -- 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]

1514   Creating temporary to copy 'Type' to 'Type' (context: Context)
       -- 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]

1515   Default constructor not available for member 'Symbol'  -- 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.

1516   Data member hides inherited member 'Symbol' (Location)  -- 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().

1520   Multiple assignment operators for class 'Symbol'  -- 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?

1521   Multiple copy constructors for class 'Symbol'  -- 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.

1522   Symbol 'Symbol' is an array of empty objects  -- 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.

1524   new in constructor for class 'Name' which has no explicit
       destructor  -- A call to new has been found in a constructor for
       a class for which no explicit destructor has been declared.  A
       destructor was expected because how else can the storage be
       freed?  [10, §12.5]

1526   Member function 'Symbol' (Location) not defined  -- A member
       function (named in the message) of a non-library class was not
       defined.  This message is suppressed for unit checkout (-u
       option).

1527   static member 'Symbol' (Location) not defined  -- 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.

1528   call to String does not match function template String  -- 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.

1529   Symbol 'Symbol' not first checking for assignment to this  -- 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)

1531   Symbol 'Symbol' (Location) should have compared argument against
       sizeof(class)  -- 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.

1532   Symbol 'Symbol' not checking argument for NULL  -- 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.

1533   Repeated friend declaration for symbol 'Symbol'  -- A friend
       declaration for a particular symbol (class or function) was
       repeated in the same class.  Usually this is a harmless
       redundancy.

1534   static variable 'Symbol' found within inline function in header
       -- 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].

1535   Exposing low access data through member 'Symbol'  -- A member
       function is returning an address being held by the indicated
       member symbol (presumably a pointer).  The member's access (such
       as private or protected) is lower than the access of the function
       returning the address.

1536   Exposing low access member 'Symbol'  -- A member function is
       returning the non-const address of a member either directly or
       via a reference.  Moreover, the member's access (such as private
       or protected) is lower than the access of the function returning
       the address.  For example:
       
                   class X
                       {
                     private:
                       int a;
                     public:
                       int *f() { return &a; }
                       };

       This looks like a breach of the access system [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; }

1537   const function returns pointer data member 'Symbol'  -- 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.

1538   base class 'Name' absent from initializer list for copy
       constructor  -- 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 ) { ... }
                       ...
                       };

1539   member 'Symbol' (Location) not assigned by assignment operator
       -- 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.

1540   pointer member 'Symbol' (Location) neither freed nor zero'ed by
       destructor  -- 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).

1541   member 'Symbol' (Location) possibly not initialized by
       constructor  -- 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.

1542   member 'Symbol' (Location) possibly not initialized  -- 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.

1543   member 'Symbol' (Location) possibly not initialized  -- 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.

1544   value of variable 'Symbol' (Location) indeterminate (order of
       initialization)  -- 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.

1545   value of variable 'Symbol' used previously to initialize variable
       'Symbol' (Location)  -- 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.

1546   direct throw of exception 'Name' within destructor 'Symbol'  --
       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]

1547   Assignment of array to pointer to base class (Context)  -- An
       assignment from an array of a derived class to a pointer to a
       base class was detected.  For example:
       
                   class B { };
                   class D : public B {};
                   D a[10];
                   B *p = a;      // Warning 1547
                   B *q = &a[0];  // OK

       In this example p is being assigned the address of the 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].

1548   Exception specification for 'Symbol' conflicts with Location  --
       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.

1549   Exception thrown for function 'Symbol' not declared to throw  --
       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]

1550   exception 'Name' thrown by function 'Symbol' is not on throw-list
       of function 'Symbol'  -- 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]

1551   function may throw exception 'Name' in destructor 'Symbol'  -- 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].

1552   Converting pointer to array-of-derived to pointer to base  --
       This warning is similar to Warning 1547 and is sometimes given in
       conjunction with it.  It uses value tracking to determine that an
       array (that could be dynamically allocated) is being assigned to
       a base class pointer.

       For example,
       
                   Derived *d = new Derived[10];
                   Base *b;
                   b = d;      // Warning 1552
                   b = &d[0];  // OK

       [23, Item 3]  Also, see the article by Mark Nelson (Bug++ of the
       Month, Windows developer's Journal, May 1997, pp. 43-44).

1553   struct 'Symbol' declared as extern "C" contains C++ substructure
       'Symbol' (Location)  -- A C++ substructure was found in a
       structure or class declared as extern "C".  Was this intended?

1554   Direct pointer copy of member 'Symbol' within copy constructor:
       'Symbol'  -- In a copy constructor a pointer was merely copied
       rather than recreated with new storage.  This can create a
       situation where two objects have the same data and this, in turn,
       causes problems when these objects are deleted or 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.

1555   Direct pointer copy of member 'Symbol' within copy assignment
       operator: 'Symbol'  -- In a copy assignment operator a pointer
       was merely copied rather than recreated with new storage.  This
       can create a situation where two objects have the same data and
       this, in turn, causes problems when these objects are deleted or
       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.

1556   'new Type(integer)' is suspicious  -- 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.

1557   const member 'Symbol' is not initialized  -- 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.

1558   virtual coupled with inline is an unusual combination  -- 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.

1559   Uncaught exception 'Name' may be thrown in destructor 'Symbol'
       -- The named exception occurred within a try block and was either
       not caught by any handler or was caught but then thrown from the
       handler.  Destructors should normally not throw exceptions [23,
       Item 11].

1560   Uncaught exception 'Name' not on throw-list of function 'Symbol'
       -- A direct or indirect throw of the named exception occurred
       within a try block and was either not caught by any handler or
       was rethrown by the handler.  Moreover, the function has an
       exception 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.

1561   Reference initialization causes loss of const/volatile integrity
       (Context)  -- 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.

1562   Exception specification for 'Symbol' is not a subset of 'Symbol'
       (Location)  -- 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.

1563   Suspicious third argument to ?: operator  -- The third argument
       to ?: contained an unparenthesized assignment operator such as
       
                 p ? a : b = 1
       
       If this is what was intended you should parenthesize the third
       argument as in:
       
                 p ? a : (b = 1)
       
       Not only is the original form difficult to read but C, as opposed
       to C++, would parse this as:
       
                 (p ? a : b) = 1
       
1564   Assigning a non-zero-one constant to a bool  -- 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.

1565   member 'Symbol' (Location) not assigned by initializer function
       -- 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.

1566   member 'Symbol' (Location) might have been initialized by a
       separate function but no '-sem(Name,initializer)' was seen  -- A
       class data member (whose name and location are indicated in the
       message) was not directly initialized by a constructor.  It may
       have been initialized by a separately called member function.  If
       this is the case you may follow the advice given in the message
       and use a semantic option to inform PC-lint/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.

1567   Initialization of variable 'Symbol' (Location) is indeterminate
       as it uses variable 'Symbol' through calls: 'String'  -- 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.

1568   Variable 'Symbol' (Location) accesses variable 'Symbol' before
       the latter is initialized through calls: 'String'  -- 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.

1569   Initializing a member reference with a temporary.  -- 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]

1570   Initializing a reference class member with an auto variable
       'Symbol'  -- In a constructor initializer, a reference class
       member is being initialized to bind to an auto variable.
       Consider:
       
             class X { int &n; X(int k) :n(k) {} };
       
       In this example member n is being bound to variable k which,
       although a parameter, is nonetheless placed into auto storage.
       But the lifetime of k is only the duration of the call to the
       constructor, whereas the lifetime of n is the lifetime of the
       class object constructed.

1571   Returning an auto variable 'Symbol' via a reference type  -- A
       function that is declared to return a reference is returning an
       auto variable (that is not itself a reference).  The auto
       variable is not guaranteed to exist beyond the lifetime of the
       function.  This can result in unreliable and unpredictable
       behavior.

1572   Initializing a static reference variable with an auto variable
       'Symbol'  -- A static variable has a lifetime that will exceed
       that of the auto variable that it has been bound to.  Consider
       
             void f( int n ) { static int& r = n; ... }
       
       The reference r will be permanently bound to an auto variable n.
       The lifetime of n will not extend beyond the life of the
       function.  On the second and subsequent calls to function f the
       static variable r will be bound to a non-existent entity.

1573   Generic function template 'Symbol' declared in namespace
       associated with type 'Symbol' (Location)  -- 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.

1574   Returning the address of an auto variable indirectly through
       reference variable 'Symbol'  -- 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;
                 }
       

1576   Explicit specialialization does not occur in the same file as
       corresponding function template 'Symbol' (Location)  -- 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.

1577   Partial or explicit specialialization does not occur in the same
       file as primary template 'Symbol' (Location)  -- 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.

1578   Pointer member 'Symbol' (Location) neither freed nor zeroed by
       cleanup function  -- The indicated member is a non-static data
       member of a class that was apparently not cleared by a function
       that had previously been given the cleanup semantic.  By clearing
       we mean that the pointer was either zeroed or the storage
       associated with the pointer released via the free function or its
       semantic equivalent or some form of delete.  See also Warning
       1540.

1579   Pointer member 'Symbol' (Location) might have been freed by a
       separate function but no '-sem(Name,cleanup)' was seen  -- A
       class data member (whose name and location are indicated in the
       message) was not directly freed by the class destructor.  There
       was a chance that it was cleared by a separately called member
       function.  If this is the case you may follow the advice given in
       the message and use a semantic option to inform PC-lint/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.



19.10  C++ Informational Messages

1701   redundant access-specifier 'String'  -- The given access
       specifier (one of 'public', 'private' or 'protected') has been
       repeated.  [11, §11.1]

1702   operator 'Name' is both an ordinary function 'String' and a
       member function 'String'  -- 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]

1703   Function 'String' arbitrarily selected.  Refer to Error 'Integer'
       -- 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]

1704   Constructor 'Symbol' has private access specification  -- 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.

1705   static class members may be accessed by the scoping operator  --
       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]

1706   Declaration with scope operator is unusual within a class  --
       Class members within a class are not normally declared with the
       scope operator.  For example:

               class X  {  int X::n; ...

       will elicit this message.  If the (redundant) class specification
       (X::) were replaced by some different class specification and the
       declaration was not friend an error (1040) would be issued.  [11,
       §9.2]

1707   static assumed for String  -- 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]

1708   typedef 'Symbol' not declared as "C" conflicts with Location  --
       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.

1709   typedef 'Symbol' declared as "C" conflicts with Location  -- 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.

1710   An implicit 'typename' was assumed  -- 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).

1711   class 'Symbol' (Location) has a virtual function but is not
       inherited  -- The given class has a virtual function but is not
       the base class of any derivation.  Was this a mistake?  There is
       no advantage to making member functions virtual unless their
       class is the base of a derivation tree.  In fact, there is a
       disadvantage because there is a time and space penalty for
       virtual functions.  This message is not given for library classes
       and is suppressed for unit checkout.  [13, §4]

1712   default constructor not defined for class 'Name'  -- 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]


1713   Parentheses have inconsistent interpretation  -- 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.

1714   Member function 'Symbol' (Location) not referenced  -- A member
       function was not referenced.  This message is automatically
       suppressed for unit checkout (-u) and for members of a library
       class.

1715   static member 'Symbol' (Location) not referenced  -- 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.

1716   Virtual member function 'Symbol' (Location) not referenced  -- 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).

1717   empty prototype for function declaration, assumed '(void)'  -- 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]

1718   expression within brackets ignored  -- 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]

1719   assignment operator for class 'Symbol' has non-reference
       parameter  -- 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]

1720   assignment operator for class 'Symbol' has non-const parameter
       -- 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]

1721   operator =() for class 'Symbol' is not assignment operator  --
       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]

1722   assignment operator for class 'Symbol' does not return a
       reference to class  -- 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]

1724   Argument to copy constructor for class 'Symbol' should be a const
       reference  -- 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]

1725   class member 'Symbol' is a reference  -- 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]

1726   taking address of overloaded function name 'Symbol'  -- 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]

1727   inline 'Symbol' not previously defined inline at (Location)  -- 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]

1728   Symbol 'Symbol' was previously defined inline at (Location)  -- 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]

1729   Initializer inversion detected for member 'Symbol'  -- 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]

1730   class/struct inconsistency for symbol 'Symbol' (conflicts with
       Location)  -- 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]

1732   new in constructor for class 'Name' which has no assignment
       operator  -- 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]

1733   new in constructor for class 'Name' which has no copy constructor
       -- 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]

1734   Had difficulty compiling template function: 'Symbol'  -- 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.

1735   Virtual function 'Symbol' has default parameter  -- 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].

1736   Redundant access specifier (String)  -- 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.

1737   Symbol 'Symbol' hides global operator new  -- 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].

1738   non-copy constructor 'Symbol' used to initialize copy constructor
       -- 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.

1739   Binary operator 'Symbol' should be non-member function  -- 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].

1740   pointer member 'Symbol' (Location) not directly freed or zero'ed
       by destructor  -- 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.

1741   member 'Symbol' (Location) conceivably not initialized by
       constructor  -- 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.

1742   member 'Symbol' (Location) conceivably not initialized  -- 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.

1743   member 'Symbol' (Location) conceivably not initialized  -- 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.

1744   member 'Symbol' (Location) possibly not initialized by private
       constructor  -- 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.

1745   member 'Symbol' (Location) not assigned by private assignment
       operator  -- 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]

1746   parameter 'Symbol' of function 'Symbol' could be made const
       reference  -- 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].

1747   binary operator 'Symbol' returning a reference  -- 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 & );

1748   non-virtual base class 'Name' included twice in class 'Name'  --
       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.

1749   base class 'Symbol' of class 'Symbol' need not be virtual  -- 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.

1750   local template 'Symbol' (Location) not referenced  -- 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.

1752   catch parameter Integer is not a reference  -- 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].

1753   Overloading special operator 'Symbol'  -- This message is issued
       whenever an attempt is made to declare one of these operators as
       having some user-defined meaning:
       
                   operator ||
                   operator &&
                   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 && 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].

1754   Expected symbol 'Symbol' to be declared for class 'Symbol'  --
       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).

1755   global template 'Symbol' (Location) not referenced  -- 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).

1757   Discarded instance of post decrement/increment  -- 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].

1758   Prefix increment/decrement operator 'Symbol' returns a
       non-reference  -- 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
                       ...
                       };

1759   Postfix increment/decrement operator 'Symbol' returns a
       reference.  -- To conform with most programming expectations, a
       postfix increment/decrement operator should return a value as
       opposed to a reference.  [23, Item 6].

1760   Redundant template 'Symbol' defined identically at Location  -- A
       template was defined identically in the same module.  Was this a
       mistake?

1761   Declaration of function 'Symbol' hides overloaded function
       'Symbol' (Location)  -- 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.

1762   Member function 'Symbol' could be made const  -- 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.

1763   Member function 'Symbol' marked as const indirectly modifies
       class  -- 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.

1764   Reference parameter 'Symbol' (Location) could be declared const
       reference  -- 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.

1768   Virtual function 'Symbol' has an access (String) different from
       the access (String) in the base class (String) -- 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).

1769   Member or base class 'Symbol' has no constructor  -- 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.

1770   function 'Symbol' defined without function 'String'  -- 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.

1771   function 'Symbol' replaces global function  -- 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]

1772   Assignment operator 'Symbol' is not returning *this  -- 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]

1773   Attempt to cast away const (or volatile)  -- 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].

1774   Could use dynamic_cast to downcast ptr to polymorphic type
       'Symbol'  -- 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.

1775   catch block does not catch any declared exception  -- 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.

1776   Converting string literals to Type is not const safe (Context)
       -- 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.

1777   Template recursion limit (Integer) reached, use -tr_limit(n)  --
       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.

1778   Assignment of string literal to variable 'Symbol' (Location) is
       not const safe  -- 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.

1780   Returning address of reference parameter 'Symbol'  -- 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].

1781   Passing address of reference parameter 'Symbol' into caller
       address space  -- 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].

1782   Assigning address of reference parameter 'Symbol' to a static
       variable  -- 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].

1784   Symbol 'Symbol' previously declared as "C", compare with Location
       -- 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.

1785   Implicit conversion from Boolean (Context) (Type to Type)  -- 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.

1786   Implicit conversion to Boolean (Context) (Type to Type)  -- 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.

1787   Access declarations are deprecated in favor of using declarations
       -- 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
                     };
       
1788   Variable 'Symbol' (Location) (type 'Name') is referenced only by
       its constructor or destructor  -- 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).

1789   Template constructor 'Symbol' cannot be a copy constructor  --
       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].

1790   Base class 'Symbol' has no non-destructor virtual functions  -- 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].

1791   No token on this line follows the 'return' keyword  -- 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.

1792   Assignment operator for class 'Symbol' does not return a const
       reference to class  -- 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.

1793   While calling 'Symbol': Initializing the implict object parameter
       'Type' (a non-const reference) with a non-lvalue  -- 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.

1794   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)
       -- 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.
1795   Defined template 'Symbol' was not instantiated.  -- 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.

1796   Explicit specialization of overloaded function template 'Symbol'
       -- 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.




19.11  C++ Elective Notes

1901   Creating a temporary of type 'Symbol'  -- 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.

1902   useless ';' follows '}' in function definition  -- 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).

1904   Old-style C comment  -- For the real bridge-burner one can hunt
       down and remove all instances of the /* ... */ form of comment.
       [12, Item 4]

1905   implicit default constructor generated for class 'Name'  -- 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.

1907   implicit destructor generated for class 'Name'  -- 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]

1908   'virtual' assumed for destructor'~Name()' (inherited from base
       class 'Name()  -- 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.

1909   'virtual' assumed, see:  function 'Symbol' (Location)  -- 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.

1911   Implicit call of constructor 'Symbol' (see text)  -- 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]

1912   Implicit call of conversion function from class 'Name' to type
       'Type'  -- 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.

1914   Default constructor 'Symbol' (Location) not referenced  -- 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.

1916   Ellipsis encountered  -- 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++.

1917   Empty prototype for String, assumed '(void)'  -- 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]

1918   empty prototype for member declaration, assumed (void)  -- 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]

1919   Multiple assignment operators for class 'Symbol'  -- 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.

1920   Casting to a reference  -- 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]

1921   Symbol 'Symbol' not checking argument against sizeof(class)  --
       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).

1922   Symbol 'Symbol' not checking argument for NULL  -- 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.

1923   macro 'Symbol' could become const variable  -- 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.

1924   C-style cast  -- 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].

1925   Symbol 'Symbol' is a public data member  -- 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]

1926   Symbol 'Symbol's default constructor implicitly called  -- 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].

1927   Symbol 'Symbol' did not appear in the constructor initializer
       list  -- 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].

1928   Symbol 'Name' did not appear in the constructor initializer list
       -- 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].

1929   function 'Symbol' returning a reference  -- 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].

1930   Conversion operator 'Symbol' found  -- 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].

1931   Constructor 'Symbol' can be used for implicit conversions  -- 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.

1932   Base class 'Symbol' is not abstract.  -- 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.

1933   Call to unqualified virtual function 'Symbol' from non-static
       member function  -- 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.

1934   Shift operator 'Symbol' should be non-member function  -- 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.

1935   Dynamic initialization for class object 'Symbol1' (references
       'Symbol2')  -- 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.

1936   Dynamic initialization for scalar 'Symbol1' (references
       'Symbol2')  -- 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.

1937   Static variable 'Symbol' has a destructor.  -- 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.

1938   constructor 'Symbol' accesses global data.  -- 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]

1939   Down cast detected  -- 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]

1940   Address of reference parameter 'Symbol' transferred outside of
       function  -- 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.

1941   Assignment operator for class 'Symbol' does not return a const
       reference to class  -- 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.

1942   Unqualified name 'Symbol' subject to misinterpretation owing to
       dependent base class  -- 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.

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

       The list of checks made are as follows:

       (Rule 0-1-8)    Void return type for function without external side-effects.
       (Rule 2-13-2)   Octal constant or escape sequence used.
       (Rule 2-13-4)   Lower case literal suffix.
       (Rule 3-1-1)    Object/function definitions in headers.
       (Rule 3-1-2)    Function not declared at file scope.
       (Rule 5-0-3)    Implicit conversion of cvalue.
       (Rule 5-0-4)    Implicit conversion changes signedness.
       (Rule 5-0-5)    Implicit conversion between integer and floating point types.
       (Rule 5-0-6)    Implicit conversion to smaller type.
       (Rule 5-0-7)    Cast of cvalue between integer and floating point types.
       (Rule 5-0-8)    Cast of cvalue to larger type.
       (Rule 5-0-9)    Cast of cvalue changes signedness.
       (Rule 5-0-10)   Recasting required for operators '~' and '<<'.
       (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.

1961   virtual member function 'Symbol' could be made const  -- 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.

1962   Non-const member function 'Symbol' contains a deep modification.
       -- 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.

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

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

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