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.

                          C             C++           Warning Level

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


                                Glossary

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

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

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

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

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

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

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

scalar    Any of the arithmetic types plus pointers.

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

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

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

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

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


                           Message Parameters

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

Char      Some character

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

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


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

Integer   Some integer

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

Kind      A list of control structures.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     o    size -- Two arrays differ in array dimension.

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

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

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

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

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



Top
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
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
19.2  Internal Errors

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.


Top
19.3  Fatal Errors

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


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
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
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 13.4 C Informational Messages and flags -fiw and -fiz in
      Sections 2.3.6 Initialization-is-considered-a-Write flag (-fiw)
      and 2.3.7 Initialization-by-Zero-is-considered-a-Write flag
      (-fiz) .

      This message is suppressed if the variable's address is assigned
      to a pointer (or, equivalently, the variable is used to directly
      initialize a reference to non-const).

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
   for loop index variable 'Symbol' modified in body of the for loop
      -- A for loop with an identifiable loop index variable was
      programmed in such a way that the loop body also modifies the
      index variable.  For example:
       
                for( i = 0; i < 100; i++ )
                    {
                    a[i++] = 0;
                    }
       
      In general it is better to restrict modifications to for loop
      index variables to the for clause if at all possible.  If this is
      not possible, you can prefix the for loop with an appropriate
      lint comment such as:
       
                /*lint -e{446} i is modified in the body of the for loop */
       

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 13.5 C Elective Notes.

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 4. Semantics ).  However, an impurity was detected.  Such
      impurities include calling a function through a function pointer,
      accessing a volatile variable, modifying a static variable or
      calling a function whose purity PC-lint/FlexeLint cannot verify.
      String describes which of these reasons apply and Name shows the
      related variable or function, as appropriate.

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

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 (Symbol3) 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 8. Multi-thread Suppport to determine what those
      conditions might be.

      If a function's address is taken, we presume that we are unable
      to determine statically all the locations from which the function
      may be called and so we presume that any and all threads can call
      this function and so the function needs to have protected access
      to every static variable that it might touch.

      There are several remedies to such a message.  If multiple
      threads can indeed access this function, then place a mutex lock
      in the function.  If there already is a mutex lock and we don't
      recognize it, then set the thread_protected semantic for the
      function.  If only one thread really accesses this function or if
      the access is guaranteed to be benign, then, after making sure
      this condition is commented in the code, use the same
      thread_protected semantic for the function.

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 8.
      Multi-thread Support 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
501
   Expected signed type  -- The unary minus ope