Gimpel Home Page On-Line Message Reference for FlexeLint and PC-lint (aka FlexeLint for Windows)

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-2009  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.  Lint also provides an additional
set of elective notes in the 9000 range to help support various coding
guidelines.  Like the traditional Elective Notes, these messages are not
automatically outputted.

                          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
Elective Notes         9000 - 9099   Same                  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 .

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

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

Top
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.

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

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

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

Top
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.

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

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

Top
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.

Top
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.

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

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

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

Top
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.

Top
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.

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

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

Top
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.

Top
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;;

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

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

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

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

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

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

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

Top
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.

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

Top
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.

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

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

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

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

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

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

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

Top
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.

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

Top
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.

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

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

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

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

Top
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).

Top
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.

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

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

Top
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.

Top
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).

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

Top
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).

Top
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.

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

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

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

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

Top
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).

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

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

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

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

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

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

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

Top
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.)

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

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

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

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

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

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

Top
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.

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

Top
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.

Top
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.

Top
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).

Top
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.

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

Top
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.

Top
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.

Top
82
    return ; 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.

Top
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.

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

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

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

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

              #if ABC == "abc"

      Such expressions should be integral expressions.

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

Top
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.

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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
     

Top
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 };
     

Top
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.

Top
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.

Top
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 (> >= < <=).

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

Top
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.

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

Top
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 (> >= < <=).

Top
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 '['

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

Top
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.

Top
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.

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

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

Top
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 (}).

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

Top
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.

Top
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.

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

Top
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.

Top
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.

Top
142
   case constant 'String' used previously in this switch -- A
      duplicate case constant was detected.  For example, the following
      code will be diagnosed as a repetition of case constant '1'.
     
          switch( n )
              {
              case 1:  m = 25;    break;
              case 2-1: m = 27;   break;
              }
     

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

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

Top
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;

Top
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.

Top
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( ).

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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).

Top
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.

Top
165
   An [unscoped] enumeration cannot be forward-declared [without an
      enum-base] (int is assumed) -- This message is issued at the
      point of a forward-declaration of an enumeration like so:
     
              enum E; // Error
     
      This is prohibited by ISO C and ISO C++98.  In C++0x, we can
      modify this example to be well-formed by explicitly indicating
      the underlying integral type; example:
     
              enum E : unsigned short; // Ok
     
      If you are not using C++0x and/or your compiler supports the
      construct you may simply suppress this message with a -e165.

Top
166
   Function defined within a function -- A function definition was
      found within the body of another function's definition.  Such a
      construct is almost certainly an error.

Top
170
   Explicit type-specifier required for symbol 'Symbol', int assumed
      -- A declaration did not have an explicit type as required by C99
      or C++.  int was assumed.  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;
     

Top
171
   Ellipsis requires at least one parameter-declaration -- A
      function declaration was seen with '...' but no
      parameter-declaration before it, as required by the ISO C syntax.
      This diagnostic is not given for C++ code.


Top
2
   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 ------

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


Top
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.

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

Top
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.

Top
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.

Top
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.

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

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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.

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

Top
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.

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

Top
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).

Top
318
   EOF for a module found within a macro argument list -- We found
      the end of a module within the argument list of a macro.  Since
      such situations are almost certain to be erroneous, we gracefully
      shut down, alerting the User to the reason.

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

Top
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.

Top
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).

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

Top
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.

Top
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.

Top
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.

Top
333
   Not allowed to open file 'String' -- A 'forbidden' file was
      opened.  Opening such a file is considered a security violation
      by a hosted implementation.

                 ------ 19.4 C Warning Messages ------

Top
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.

Top
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).

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

Top
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.

Top
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?

Top
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?

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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'.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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

Top
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.

Top
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)'

Top
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 (//).

Top
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.

Top
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.

Top
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.

Top
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?

Top
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 )

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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  and flags -fiw
      and -fiz in Sections  and
      .

      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).

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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++ ) { ... }
                  }
     

Top
446
   side effect in initializer -- An initializer containing a side
      effect can be potentially troublesome. For example, given the
      code:
     
          void f( int i )
              {
              int a[2] = {i++, i++};
              }
     
      The values of the array elements are unspecified because the
      order of evaluation is unspecified by the C standard.

Top
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.

Top
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.

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

Top
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 .

Top
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.

Top
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  ).  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.

Top
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
                  ...
     
Top
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
                  }
     
Top
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.

Top
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.

Top
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.

Top
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  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.

Top
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.

Top
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
       to obtain further information on
      thread unsafe function groups and options to determine them.

Top
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.

Top
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 );
     

Top
483
   boolean value in switch expression -- At least one standards
      organization has expressed the perspective, if the expression of
      a switch-statement is boolean in nature, if-else should be used
      instead.

Top
484
   Stringize operator followed by macro parameter followed by
      pasting operator -- Due to order of evaluation issues, the mixing
      of stringizing and pasting operators, particularly when appearing
      in the order # parameter ##, results in unspecified behavior.

Top
485
   Duplicate initialization of object element -- This message is
      given upon an inconsistent use of designated initializers (used
      for specific fields of arrays or structures).  It is possible for
      an element of such an aggregate to be initialized twice either
      through the use of two separate designators or through a
      designator and the conventional sequential initialization
      process.  In either case the end result is not specified and the
      construction is usually a sign of a logic error.

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
510
   File extension 'String' reserved for future versions of this
      product -- File name extensions that are not those recognized as
      implying C++ source code or indirect files for lint or
      pre-compiled headers for lint or lint object modules or project
      files are assumed to be C source code.  If we recognize a new
      file extension in some future version of lint it can be
      beneficial to warn about the use of this file extension in any
      earlier version of lint.  One reason for this is to aid in the
      transition between versions of the product.  During this
      transition period a new file extension may be provided
      unintentionally to a former version of the product resulting in
      surprising behavior.

Top
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.

Top
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.

Top
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).

Top
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.

Top
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.

Top
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.

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

Top
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.

Top
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).

Top
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).

Top
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 

Top
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.

Top
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.

Top
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.

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

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

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

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

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

Top
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.

Top
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.)

Top
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.

Top
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.

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

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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".

Top
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".

Top
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.

Top
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.

Top
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 #.

Top
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).

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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
     
Top
586
   String 'Name' is deprecated. String -- The Name has been
      deprecated by some use of the deprecate option.  See Section
      .  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.

Top
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'.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
598
   Excessive shift value (precision Integer shifted left by Integer)
      -- A quantity is being shifted to the left by a value greater
      than or equal to the precision of that quantity or by a negative
      value. For example,

        i << 32

      will elicit this message if i is typed int and where int is 32
      bits wide or less (the usual case). Such shift results in
      undefined behavior. To suppress the message you may cast the
      shifted quantity to a type whose length is at least the length of
      the shift value.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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'.

Top
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.

Top
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).

Top
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?

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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".

Top
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.

Top
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.

Top
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.

Top
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".

Top
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".

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

Top
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.

Top
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.

Top
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.

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

Top
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.

Top
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.

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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).

Top
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.

Top
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.

Top
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.

Top
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++.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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( ... )
     
Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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);

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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 following reasons for issuing this message
      exist:

      o  unbalanced quotes -- An option was seen with a quote character
      which was not balanced within that same option.

      o  backtick preceding non-meta character is superfluous and has
      been dropped -- A backtick (`) was seen before a character other
      than a * or a ?. The use of a backtick in this fashion has no
      effect.

      o  Upper case characters within extension 'String'; these will
      match lower case when +fff is on; try -fff -- A file extension
      involving capital letters was seen in a +cpp(), +lnt(), or +ext()
      option while the +fff flag was active. If, for example, you
      intend for .c to indicate a C module and .C to indicate a C++
      module, turning off the fff flag will help avoid unnecessary
      complaints from Lint.

      o  extraneous characters following String -- One or more
      characters were seen immediately following a character which is
      expected to signify the end of an option, such as a closing right
      parenthesis. While the extraneous characters are ignored, their
      presence may indicate a typographical error.

      o  missing field-specifier in a non-empty format string [No data
      will be generated for this category.] -- A -program_info() option
      was expecting a field-specifier which was actually missing. As
      noted, no data for this particular category will be generated.

      o  the likelihood of causing meaningless output -- An option,
      such as -elib(*), -wlib(0), or +fce was seen; this typically
      hides a problem in the Lint configuration. When using a new Lint
      configuration, it's common for a user to encounter Error messages
      from Lint about library header code. (This usually does not
      indicate a problem with library headers.) For example, a
      misconfiguration of Lint's preprocessor is by far the most common
      source of these errors.  If you merely suppress basic Syntax
      Errors (like Error 10) and/or Fatal Errors (like Error 309), the
      underlying Lint configuration problem still exists; as a result,
      Lint will fail to parse your code correctly (because your code
      depends on the aforementioned library code). The output from Lint
      would then seem illogical and/or meaningless. Therefore, blanket
      suppression options like this are highly discouraged.  Instead,
      other aspects of the Lint configuration should be modified to
      make Lint's behavior more similar to that of the compiler at (or,
      typically, before) the point of the Error.

      o  a lack of an argument -- A -message() was found to not include
      text between the parentheses, rendering the option meaningless.
      Did the User possibly intend to include the text immediately
      after this option?

Top
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.

Top
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.

Top
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.

Top
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  and 

Top
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 */ \
     
Top
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).

Top
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.

Top
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.

Top
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'.

Top
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).

Top
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.

Top
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 ------


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

Top
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).

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

Top
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).

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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).

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

Top
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(;;).

Top
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

Top
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.

Top
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.

Top
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 ==.

Top
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.

Top
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.

Top
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?

Top
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.

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

Top
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.

Top
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.

Top
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).

Top
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.

Top
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.

Top
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.

Top
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.

Top
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).

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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 *.

Top
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.

Top
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.

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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).

Top
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).

Top
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).

Top
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).

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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."

Top
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]

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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?

Top
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.

Top
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.

Top
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.

Top
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.

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

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

Top
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)"

Top
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.

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

Top
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.

Top
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'.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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").

Top
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").

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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) );

Top
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.

Top
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; }

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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 () would have been issued.  This message (836) could be
      issued if there were some intervening code involving k.  See also
      .

Top
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 .

Top
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.

Top
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.

Top
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  and message 844.

Top
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  and message 843.

Top
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.
       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;
     
Top
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.

Top
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  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.

Top
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.

Top
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.

Top
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.

Top
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).

Top
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().
     

Top
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  and .


                  ------ 19.6 C Elective Notes ------

Top
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.

Top
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.

Top
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  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
      

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

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

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

Top
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.

Top
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.

Top
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.

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

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

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

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

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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).

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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 16/12.12) Bit representation of a floating point type used.
      (Rule 19/7.1) Octal constant used.
      (Rule 22/8.7) Could define variable at block scope.
      (Rule 27/8.8) Object/function previously declared.
      (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 34/12.5) Non-primary expression used with logical operator.
      (Rule 36/12.6) Boolean expression required for operator.
      (Rule 40/12.3) 'sizeof' used on expressions with side effect 
      (Rule 42/12.10) Comma operator used outside of 'for' expression.
      (Rule 47/12.1) Dependence placed on C operator precedence.
      (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 60/14.10) No 'else' at end of 'if ... else if' chain.
      (Rule 63/15.4) Boolean value in switch expression.
      (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 74/16.4) Parameter list differs from prior declaration for function.
      (Rule 87/19.1) Declaration before #include.
      (Rule 88/19.2) Header file name with non-standard character.
      (Rule 91/19.5) '#define/#undef' used within a block.
      (Rule 92/19.6) Use of '#undef' prohibited.
      (Rule 98/19.12) Multiple use of '#' and/or '##' operators in macro definition.
      (Rule 100/19.14) Non-standard use of 'defined' preprocessor operator.
      (Rule 115/20.2) Re-use of C90 identifier/identifier pattern.

      Required checks made exclusively for MISRA 1998 are:

      (Rule 8) Multibyte characters and wide string literals prohibited.
      (Rule 42) Comma operator used outside of 'for' expression.
      (Rule 54) Null statement not in line by itself.
      (Rule 58) break used outside of a switch.
      (Rule 73) Either all parameters or no parameters should have identifiers.
      (Rule 87) Declaration before #include.
      (Rule 88) Header file name contains non-standard character.
      (Rule 110) Bitfields inside union.

      Required checks made exclusively for MISRA 2004 are:

      (Rule 4.1) Prohibited escape sequence used.
      (Rule 6.1) Disallowed use of non-character value.
      (Rule 6.2) Disallowed use of non-numeric value.
      (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 10.6) Unsigned integer literals require a 'U' suffix.
      (Rule 11.5) Attempt to cast away const/volatile from a pointer or reference.
      (Rule 12.7) Bitwise operator applied to signed underlying type.
      (Rule 12.9) Prohibited operator applied to unsigned underlying type.
      (Rule 12.10) Comma operator used.
      (Rule 12.13) Increment or decrement combined with another operator.
      (Rule 14.3) Null statement not in line by itself.
      (Rule 14.6) More than one 'break' terminates loop.
      (Rule 14.8) Left brace expected.
      (Rule 16.3) All parameters shall have identifiers.
      (Rule 16.9) Function identifier used without '&' or parenthesized parameter list.
      (Rule 17.4) Pointer arithmetic other than array indexing used.
      (Rule 18.4) Unions shall not be used.
      (Rule 19.13) '#/##' operator used in macro.

      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.

Top
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.

Top
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.

Top
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]
      (), provide convincing evidence
      that this alternative convention is indeed the better one.

Top
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.

Top
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.

Top
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  for more information
      about header include guards.

Top
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)

Top
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.

Top
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.

Top
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.

Top
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  and .


                 ------ 19.7 C++ Syntax Errors ------
Top
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]

Top
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]

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

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

Top
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]

Top
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.

Top
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]

Top
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]

Top
1009
  operator 'String' not redefinable -- The three operators:
     
          .*   ?   .
     
      are not redefinable and may not be overloaded [11, 13.4].

Top
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]

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

Top
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]

Top
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]

Top
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.

Top
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]

Top
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]

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

Top
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]

Top
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]

Top
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 { };           // 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.

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

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

Top
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]

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

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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.

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
1048
  expected a constant expression -- Within a template argument list
      a constant expression was expected.  An expression of the form
      T 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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
1054
  template variable declaration expects a type, int assumed -- An
      expression of the form T was encountered.  One of
      the arguments corresponding to a type parameter in the original
      template declaration is not a type.  [10, 14.5]

Top
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]

Top
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]

Top
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]

Top
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(...);

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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].

Top
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].

Top
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.

Top
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.

Top
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.

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

Top
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.

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

      the scoped-identifier must identify a namespace.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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 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.

Top
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

Top
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
     
Top
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.

Top
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.

Top
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 A {};             //#1
          template class A {}; //#2
          template class A {}; //#3
          A a; // ambiguous: matches #2 and #3
              // (and neither template is more specialized than the other)
     

Top
1085
  Invalid definition of 'String' -- An attempt was made to define a
      member of a template before the template was defined. Example:
     
              template struct A
                      { 
                      void 
                      }; 
              template void A::f(){} // Error 1085
     
      In this case, the template argument list is out of order; T and U
      have been interchanged.

Top
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.

Top
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.
     
Top
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 , [34], 7.3.3
      namespace.udecl.

Top
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 , [35], Issue 460.

Top
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 A {
              protected:
                  template class B{};
              };

              struct D : public A {
              public:
                  using A::B; // Error 1090
                  };

              D::B bc;
     
      Instead, refer to the template name without template arguments:
     
              template class A {
              protected:
                  template class B{};
              };

              struct D : public A {
              public:
                  using A::B; // OK
                  };

              D::B bc; // OK
     
      See Section , [34], 7.3.3
      namespace.udecl.

Top
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 , [35], Issue 400.

Top
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 , [34], 7.3.3
      namespace.udecl.

Top
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".

Top
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.

Top
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
      , [34], 14.5.4 temp.class.spec.
      Example:
     
          // primary template:
          template struct B;

          // PS #1:
          template struct B; // Ok

          // PS #2:
          template struct B; // Ok, same as:
          template struct B; // Ok (redeclaration of #2)

          // PS #3:
          template struct B; // 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.

Top
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
              {}
          };
     

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

Top
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 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.)
     

Top
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 struct A {};

          template void f( T*, U    ); // #1
          template void f( T,  A ); // #2

          struct B{};
          template<> void f( B, A ); // Ok
          // #1 does not match but #2 does.

          template<> void f( char*, A ); // 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*, A ); // 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.

Top
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 struct A {};

          template inline void f( A ); // #1
          void f( A ); // #2 // Ok, declares an ordinary function

          void f( A ); // Error 1100
     

Top
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 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*)'.)

Top
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
     

Top
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
     

Top
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'
     

Top
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
              };
     

Top
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.

Top
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.

Top
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
          }
     

Top
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
     

Top
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  struct B {};

              // template <>  // Would be ill-formed by ISO C++.
              //     struct B {};
          };
          template<> struct A::B {}; // 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 struct G {
              template  struct H {};
              // template <>  // Would be ill-formed by ISO C++.
              //     struct H {};
          };
     
      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 struct J {
              template  struct K {};
          };
          // template
          //     template <>  // Would be ill-formed by ISO C++;
          //         struct J::K {};
     
      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 struct L {
              template  struct M {};
          };
          template <> template <> struct L::M {}; // Ok
     
      Here, the body of the class L is automatically generated by
      implicit instantiation (otherwise the reference to 'L::M'
      would be ill-formed), while the body of L::M is
      provided in the explicit specialization.

      In March of 2009, the ISO C++ committee reviewed a report
      submitted against this example:
     
         struct A {
            template struct B;
            template  struct B { }; // well-formed
            template <> struct B { }; // 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.

Top
1116
  Virtual function 'Symbol' overrides function marked with final --
      A derived class attempted to override a virtual function that is
      marked with the final virt-specifier in a base class.

Top
1117
  Non-virtual function 'Symbol' marked with 'String' -- A
      virt-specifier (final or override) was supplied to a non-virtual
      function.

Top
1118
  Virtual function 'Symbol' already marked with 'String' -- A
      virt-specifier (final or override) was encountered multiple times
      for the specified virtual function.

Top
1119
  Virtual function 'Symbol' marked with override does not override
      -- A virtual function was marked with the override keyword but
      does not override a base class function.


             ------ 19.8 Additional Internal Errors ------
Top
12
  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 ------
Top
1401
  member 'Symbol' (Location) not initialized by constructor -- The
      indicated member symbol was not initialized by a constructor.
      Was this an oversight?

Top
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.

Top
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.

Top
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.

Top
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  (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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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 

Top
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.

Top
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) { /* ... */ }
                  };
     

Top
1419
  Destructors should never throw -- A destructor was declared
      without a throw() specification.  At least one author has warned
      against throwing exceptions from destructors and the practice can
      result in undefined behavior.  A safer approach is to provide an
      explciit throw() for each destructor.

Top
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,...).

Top
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]

Top
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]

Top
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?

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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.

Top
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]

Top
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]

Top
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]

Top
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.

Top
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( ).

Top
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?

Top
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.

Top
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.

Top
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]

Top
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).

Top
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.

Top
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.

Top
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)

Top
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.

Top
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.

Top
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.

Top
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].

Top
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.

Top
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; }

Top
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.

Top
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 ) { ... }
                    ...
                    };

Top
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.

Top
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).

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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]

Top
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].

Top
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.

Top
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]

Top
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]

Top
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].

Top
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).

Top
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?

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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].

Top
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.

Top
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.

Top
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.

Top
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
     
Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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]

Top
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.

Top
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.

Top
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.

Top
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.

Top
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;
              }
     

Top
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.

Top
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.

Top
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.

Top
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 ------

Top
1701
  redundant access-specifier 'String' -- The given access specifier
      (one of 'public', 'private' or 'protected') has been repeated.
      [11, 11.1]

Top
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]

Top
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]

Top
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.

Top
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]

Top
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]

Top
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]

Top
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.

Top
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.

Top
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).

Top
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]

Top
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]


Top
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.

Top
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.

Top
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.

Top
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).

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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]

Top
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.

Top
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].

Top
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.

Top
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].

Top
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.

Top
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].

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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]

Top
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].

Top
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 & );

Top
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.

Top
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.

Top
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.

Top
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].

Top
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].

Top
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).

Top
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).

Top
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].

Top
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
                    ...
                    };

Top
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].

Top
1760
  Redundant template 'Symbol' defined identically at Location -- A
      template was defined identically in the same module.  Was this a
      mistake?

Top
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.

Top
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.

Top
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.

Top
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.

Top
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).

Top
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.

Top
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.

Top
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]

Top
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]

Top
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(p);   // OK
                }

      See [12, Item 21].

Top
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(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.

Top
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.

Top
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.

Top
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 A { A< A > x; };
              A a;
     
      This will result in attempts to instantiate:
     
              A
              A>
              A>>
              ...
     
      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.

Top
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.

Top
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].

Top
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].

Top
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].

Top
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.

Top
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.

Top
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.

Top
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
                  };
     
Top
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).

Top
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].

Top
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].

Top
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.

Top
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.

Top
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::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.

Top
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, ,
      [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.
Top
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.

Top
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 ------

Top
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.

Top
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).

Top
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]

Top
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.

Top
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]

Top
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.

Top
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.

Top
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]

Top
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.

Top
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.

Top
1915
  Overriding virtual function 'Symbol' is not marked with override
      -- A virtual function that overrides a base class function was
      not declared with the override virt-specifier.  This message is
      only emitted for C++11 and higher.

Top
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++.

Top
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]

Top
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]

Top
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.

Top
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]

Top
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).

Top
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.

Top
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.

Top
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(Expression) where Name is one of static_cast,
      dynamic_cast, const_cast or reinterpret_cast. [23, Item 2].

Top
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]

Top
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].

Top
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].

Top
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].

Top
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].

Top
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].

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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.

Top
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]

Top
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]

Top
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
       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.

Top
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.

Top
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.

Top
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 3-2-3)  Object/function previously declared in location.
      (Rule 3-9-3)  Bit representation of a floating point type used.
      (Rule 4-5-1)  Boolean expression used with non-permitted operator.
      (Rule 4-5-3)  Plain char used with prohibited operator.
      (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-11) Disallowed use of non-character value.
      (Rule 5-0-12  Disallowed use of non-numeric value.
      (Rule 5-0-15) Pointer arithmetic other than array indexing used.
      (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-1)  Non-postfix expression used with logical operator.
      (Rule 5-2-5)  Attempt to cast away const/volatile from a pointer or reference.
      (Rule 5-2-12) Array-pointer decay when passing the array to a function.
      (Rule 5-3-1)  Boolean expresion required for operator.
      (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-4-2)  Function parameter list differs 
      (Rule 8-4-4)  Function identifier used without '&' or parenthisized parameter list.
      (Rule 8-5-3)  Should initialize either all enum members or only the first.
      (Rule 9-5-1)  Unions shall not be used.
      (Rule 11-0-1) Non-private data member within a no-POD structure.
      (Rule 12-8-2) Public copy constructor in abstract class.
      (Rule 14-8-1) Explicit specialization of overloaded function templates.
      (Rule 15-1-2) Explicit throw of the Null macro.
      (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.
      (Rule 17-0-2) Re-use of reserved identifier

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

Top
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.

Top
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.

Top
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 5-2-10) Increment or decrement combined with another operator.
      (Rule 14-8-2) Mixing template and non-template functions in a viable sets.
      (Rule 15-0-2) Throwing a pointer expression.
      (Rule 16-2-5) Header file name with non-standard character.
      (Rule 16-3-2) No use of '#' or '##'.

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

Top
9001
  Octal constant used -- An octal constant appears in the code.
      Octal constants may be inadvertently interpreted by engineers as
      decimal values. This message is not issued for a constant zero
      written as a single digit.

Top
9003
  could define variable 'Symbol' at block scope -- A variable was
      declared at global scope but only utilized within one function.
      Moving the declaration of this variable to that function reduces
      the chance the variable will be used incorrectly.

Top
9004
  object/function 'Symbol' previously declared -- The named symbol
      was declared in multiple locations, not counting the point of
      defintion for that symbol. Declaring a symbol in one location and
      in one file helps to ensure consistency between declaration and
      definition as well as avoiding the risk of conflicting defintions
      across modules.

Top
9005
  attempt to cast away const/volatile from a pointer or reference
      -- A cast attempted to remove the qualifiers from an object to
      which a pointer points or a reference refers. Doing so can result
      in undesired or unexpected modification of the object in question
      and may result in an exception being thrown.

Top
9006
  'sizeof' used on expression with side effect -- If the operand of
      the sizeof operator is an expression, it is not usually
      evaluated.  Attempting to apply sizeof to such an expression can
      result, therefore, in code one expects to be evaluated actually
      not being evaluated and the side-effects not taking place.

Top
9007
  side effects on right hand of logical operator, 'String' -- The
      right hand side of the || and && operators is evaluated only if
      the left hand side evaluates to a certain value.  Consequently,
      code which expects the right hand side to be evaluated regardless
      of the left hand side can produce unanticipated results.

Top
9008
  comma operator used -- The comma operator is thought by some to
      reduce readability in code.

Top
9009
  floating point variable used as loop counter -- The use of
      floating point variables as loop counters can produce surprising
      behavior if the accumulation of rounding errors results in a
      different numer of iterations than anticipated.

Top
9011
  more than one 'break' terminates loop -- More than one break
      statement was seen in a loop. Minimizing the number of exits from
      a loop is thought by some to reduce visual complexity of the
      code.

Top
9012
  sub-statement should be a compound statement -- Multiple authors
      have advised making sure the body of every iteration-statement
      and selection-statement be a compound-statement. However, no {
      was seen to begin the compound-statement.

Top
9013
  no 'else' at end of 'if ... else if' chain -- An if ... else if
      chain was seen without a final else statement. Providing such a
      statement helps to act as an analog to the default case of a
      switch-statement.

Top
9014
  default missing from switch statement -- A switch-statement was
      found without a default case.  Providing such a case provides
      defensive programming.

Top
9015
  macro argument is used both with and without '#/##' and is
      subject to further replacement -- A macro argument was used both
      as an operand to the stringizing or pasting operators and not
      used as such.  Moreover, this macro argument is subject to
      further replacement.  This could cause confusion.

Top
9016
  pointer arithmetic other than array indexing used -- Array
      indexing is thought, by some, to be more readily understood and
      less error prone than other forms of pointer arithmetic.

Top
9017
  pointer arithmetic by increment or decrement used -- While at
      least one standards organization cautions against using any
      pointer arithmetic besides array indexing, the use of increment
      or decrement operators with pointers may represent an intuitive
      application and illustration of the underlying logic.
      Consequently, such constructs are separated from the prior
      message #9016 and placed under this one, allowing more fine
      tuning of Lint diagnostics.

Top
9018
  declaration of union type or object of union type, 'Type' --
      Depending upon padding, alignment, and endianness of union, as
      well as the size and bit-order of their members, the use of
      unions can result in unspecified, undefined, or implementation
      defined behavior, prompting some to advise against their use.

Top
9019
  declaration of 'String' before #include -- The symbol mentioned
      in String was seen in a module with a subsequent #include
      directive. It can be argued that collecting all #include
      directives at the beginning of the module helps improve code
      readability and helps reduce the risk of undefined behavior
      resulting from any use of the ISO standard library before the
      relevant #include directive.

Top
9020
  header file name with non-standard character 'String' -- The use
      of non-standard characters in #include directives results in
      undefined behavior.

Top
9021
  use of '#undef' is discouraged: 'String' -- The use of the #undef
      directive can lead to confusion about whether or not a particular
      macro exists at a randomly given point of code.

Top
9022
  unparenthesized macro parameter in definition of macro 'String'
      -- Multiple authors have cautioned against the use of
      unparenthesized macro parameters in cases where the parameter is
      used as an expression. If care is not taken, unparenthesized
      macro parameters can result in operator precedence rules
      producing expressions other than intended.

Top
9023
  Multiple use of '#/##' operators in definition of macro 'String'
      -- Multiple use of such operators is thought by some to increase
      the risk of undefined behavior.

Top
9024
  '#/##' operator used in macro 'String' -- The use of such
      operators is thought to reduce code clarity and increase the risk
      of undefined behavior.

Top
9025
  More than two pointer indirection levels used for type 'Type' --
      Three or more levels of pointer indirection may make it harder to
      understand the code.

Top
9026
  Function-like macro, 'String', defined -- Multiple authors have
      expressed reasons why a function, when possible, should be used
      in place of a function-like macro.

Top
9027
  Unpermitted operand to operator 'String' -- Out of concern for
      unspecified, undefined, and/or implementation defined behavior,
      some standards urge restrictions on certain types of operands
      when used with certain operators.

Top
9028
  Unpermitted arithmetic involving an essentially character type --
      MISRA C 2012 has defined the concept of essentially character
      type and placed restrictions on the use of expressions with such
      a type.

Top
9029
  Mismatched essential type categories for binary operator -- MISRA
      C 2012 has defined the concept of essential type and placed
      restrictions on the use of expressions with certain types with
      respect to binary operators.

Top
9030
  Impermissible cast -- MISRA C 2012 has defined the concept of
      essential type and placed restrictions on the use of casts
      between certain types.

Top
9031
  Composite expression assigned to a wider essential type -- MISRA
      C 2012 has defined the concepts of composite expression and
      essential type and placed restrictions on assignments of the
      former.

Top
9032
  Composite expression with smaller essential type than other
      operand -- MISRA C 2012 has defined the concepts of composite
      expression and essential type and placed restrictions on operands
      to binary operators when at least one of the operands meets the
      definition of the former concept.

Top
9033
  Impermissible cast of composite expression -- MISRA C 2012 has
      defined the concepts of composite expression and essential type
      and placed restrictions on casts of the former. This message,
      when given, is also followed by text explaining why the cast is
      considered "impermissible".

Top
9034
  Expression assigned to a narrower or different essential type --
      MISRA C 2012 has defined the concept of essential type and placed
      restrictions on assignments in relation to such types.

Top
9035
  Variable length array declared -- Some have expressed concern
      over the use of variable length arrays, noting how, even in
      common use cases of arrays, use of such arrays can result in
      undefined or unspecified behavior.

Top
9036
  Conditional expression should have essentially Boolean type --
      MISRA C 2012 has defined the concept of essentially Boolean type
      and requires that the conditional expressions of all if and
      iteration-statements comply with this definition.

Top
9037
  Conditional of #if does not evaluate to 0 or 1 -- Some urge such
      a practice in the interest of strong typing.

Top
9038
  Flexible array member declared -- Flexible array members can
      alter the behavior of sizeof in surprising ways. Additionally,
      flexible array members often require dynamic memory allocation
      which may be problematic in safety critical code.

Top
9039
  Prohibited escape sequence usage -- An octal or hexadecimal
      escape sequence has been detected within a string or character
      literal which is not immediately followed by another escape
      sequence or end of literal.  Such escape sequence usage has been
      deprecated on the grounds of potential confusion when attempting
      to read such code.

Top
9041
  goto 'Symbol' appears in block 'String' which is not nested in
      block 'String' which contains the label. -- It has been deemed
      safer by some experts that the block (i.e. compound statement)
      containing the goto should be the same as or nested within the
      block containing the label.  Thus
     
          {  label:  {  goto label;  }  }
     
      is permitted but
     
          {  goto label;  {  label:  }  }
     
      is not.  To assist the programmer, the message refers to the
      blocks using an identification code (Example: "1.2.1").  This
      identification scheme is defined as follows.
        (a) The outer block has an identification of 1.
        (b) If a particular block is identified by x then its
            immediate subblocks, if any, are identified as x.1,
            x.2, x.3, etc.

      Thus in the following 'code',
     
          {  {  }  { { label: } { } } }
     
      label: lies in block 1.2.1.

Top
9042
  departure from MISRA switch syntax -- A switch-statement was
      found which does not comply with the MISRA switch-statement
      syntax.

Top
9043
  static keyword between brackets of array declaration -- Some
      advocate against using the keyword static in array declarations
      due to a perceived increased risk of undefined behavior.

Top
9044
  function parameter modified -- It has been advocated that
      function parameters be first copied to local variables where they
      can be modified rather than modifying the parameters directly.

Top
9045
  non-hidden definition of type 'Type' -- Some advise against
      including structure definitions unless the definition is required
      for the current module.

Top
9046
  Typographical ambiguity with respect to symbol, 'Symbol',
      Reasons, Location -- Some have warned against the use of
      identifiers which may be considered typographically ambiguous. In
      addition to the name of the previously seen symbol, the reasons
      Lint considers the identifiers to be ambiguous and the location
      of said previous symbol are provided in the message, if
      available.

Top
9047
  FILE pointer dereferenced -- At least one standards organization
      urges against this practice, directly or indirectly.

Top
9048
  unsigned integer literal without a 'U' suffix -- An integer
      literal of unsigned type was found without a 'U' suffix.

Top
9049
  increment/decrement operation combined with other operation with
      side-effects -- An expression was seen involving an increment or
      decrement operator and the expression also contained potential
      side-effects other than those resulting from said operator.

Top
9050
  dependence placed on C/C++ operator precedence -- Reliance on
      operator precedence was found in a particular expression.  Using
      parentheses, it is felt, helps clarify the order of evaluation.

Top
9051
  macro 'Symbol' defined with the same name as a C keyword -- A
      macro was defined with the same name as an ISO C keyword. The use
      of such a macro causes undefined behavior.

Top
9052
  macro 'Symbol' defined with the same name as a C++ keyword -- A
      macro was defined with the same name as an ISO C++ keyword. The
      use of such a macro causes undefined behavior.

Top
9053
  the shift value is at least the precision of the essential type
      of the left hand side -- MISRA 2012 defines the notion of an
      "essential type". A quantity with a certain essential type, as
      defined by MISRA, was left shifted by a number exceeding the
      number of bits used to represent that essential type.

Top
9054
  designated initalizer used with array of unspecified dimension --
      It has been advocated, when array initializers contain
      designators, the dimension of the array should be explicitly
      stated in the declaration. The initializer of the array in
      question has been found in violation of this recommendation.

Top
9055
  Most closely enclosing compound statement of a case/default is
      not the body of a switch -- Switch labels nested inside of
      compound statements within the corresponding switch are legal but
      can reduce comprehension and lead to unstructured code.

Top
9056
  Inline function 'Symbol' defined with storage-class specifier
      'String' -- This message is issued for all inline functions
      defined with a storage-class specifier.  +estring can be used to
      find all inline functions defined with a specific specifier.  For
      example, +estring(9056, extern) will report all inline functions
      defined with extern.

Top
9057
  Lowercase L follows 'u' in literal suffix -- A lowercase letter
      "l" is used inside of a literal suffix following an upper or
      lowercase letter u.  With some fonts, the lowercase letter "l"
      can be easily confused with the number one.  This is less likely
      to happen when there is a "u" between the number and the "l" (as
      in 35ul), but some coding standards forbid the use of "l" in any
      literals.  Message 620 reports the more suspicious case where the
      "l" immediately follows a number (as in 35l).

Top
9058
  tag 'Symbol' (Location) unused outside of typedefs -- A tag was
      used only in the course of creating a typedef.  Was the tag
      unused by mistake (say a recursive reference inside the body of
      the struct was accidentally omitted)?  Such tags are most often
      redundant and can be eliminated.

Top
9059
  C comment contains C++ comment -- A C++-style comment was seen
      inside a C-style comment.  This can be confusing.

Top
9060
  trigraph in comment -- A trigraph was seen inside a comment.
      Since trigraphs are translated before preprocessing, a trigraph
      sequence like ??/ can have surprising results, especially in a
      C++ style comment where the trigraph sequence translates into a
      backslash.

Top
9066
  C++ comment contains C comment -- A C-style comment was seen
      inside a C++-style comment.  This can result in confusion.
Top
Run FlexeLint on Bug of the Month Samples
Home | Examples | Contact | Order

PC-lint and FlexeLint are trademarks of Gimpel Software
Copyright © 2011, Gimpel Software

Valid XHTML 1.0 Strict Viewable With Any Browser