bugfix80.txt

PC-Lint是一种静态代码检测工具

*   We were issuing an undeserved 1926 (default constructor implicitly
    called) for an array member of a class.

*   When a user employed the -idlen(k) option to get reports on identifiers
    that were different but identical to within k characters (Warning
    621) the programmer might receive information to the effect that
    some created symbols matched that description.  Specifically static
    variables are placed in fictitious name spaces and the names of these
    spaces formed near collisions.  We now suppress this message for
    internally generated names.


*************** Version 8.00m 9/9/2003 ***************

*   Under certain conditions repeated use of the same semantic
    would not work.  The semantic would have to involve allocation
    flags.  For example:
      -sem( f, @P == malloc(1n) )
    would work on the first invocation of f() but not on subsequent
    invocations the malloc flag would not be inserted.

*   When a modifier semantic is assigned to some new keyword as in
      -rw_asgn( shared, fortran )
    we now use the new name ('shared' in this case) to designate
    types so modified rather than the original modifier name
    ('fortran' in this case).

*   Messages issued as the result of evaluating the control expression
    of a while or for statement were sometimes issued redundantly
    up to three times.  This number has been sharply reduced.

*   When comparing two floating point constant literals we were
    not always accurately deducing the result.  For example, the
    expression
      1 / ( 1.3 > 0.0 )
    would be regarded as a possible division by 0.

*   We were crashing when an option -passes was issued without the
    trailing parenthetical expression or if the '(' was separated from
    the -passes by a blank.

*   Under NT you were unable to use the convention that .C implies
    C++ processing whereas .c implies C processing.  The reason for
    this is that filenames are normally folded so that alpha.h compares
    equal to ALPHA.H.  However, you should have been able to accomplish
    this by turning off filename folding (option -fff).   But some
    folding was still being done.  This residual folding has been removed.

*   We were not catching out-of-bound array references when the reference
    was to an array within an array of structs.  For example, assume
    all arrays are dimension 10.  Assume a is an array of structs which
    bear a member array b.   Then  a[10].b[9] = 0; would not be caught.

*   The conditional operator e0 ? e1 : e2 might give undue favoritism
    to the first branch (e1) over the second branch (e2) when both
    branches were possible even though e2 was more probable than e1.

*   A bug was found in loop combinations that would give a bogus message.
      E.g.  for( i = 0; i < n+1; i++ ) { }  a[n] = 0;
    would give an undeserved "Conceivably negative value" for the subscript

*   A -d(name)= would be greeted with a complaint (Error 72) but since
    the option was deferred to the start of the module the complaint
    would refer to the wrong option.

*   We were not properly value-tracking variables having the non-standard
    type of _bit.  Initialization values were honored but assignments
    were getting lost.
    E.g.  void f() { _bit x = 1;  x = 0;  /* we think x is still 1 */ ... }

*   We were improperly flagging some array variables as having string
    like properties.

*   The combined options +fxa (exact array) and +fsc (strings are const)
    for a C program were working in such a way as to make string constants
    incompatible with pointers to const char across the : operator
    (i.e. the 2nd and 3rd operands of the ?: ternary operator).

*   We now support for( int i = 0; ... ) within C99 programs (C99 is the
    default for C in lieu of a -A(C90) option).

*   The first user-defined function with semantic properties
    was given some additional undeserved properties.  In particular
    you might get an Unreachable Code (527) following its use.
    This normally wouldn't be experienced because the first function
    endowed with additional semantics was usually some library function
    specified with -wfprintf.

*   We were giving an undeserved 1058 (Initializing a non-const reference
    with a non-lvalue) when passing an lvalue class to a function whose
    parameter is a non-reference class and for which the required
    copy constructor is parameterized as non-const reference.  E.g.
      struct X { X( X& ); };
      void f( X );
      void g( X a ) { f( a ); }

*   We were regarding a member template as the copy assignment operator.
    Copy assignment operators can never be specialized from a template.
    For example,
      template<class T> class A
	      {
	      A& operator =(A& );
	      template<class Y> A& operator =(A<Y>& );
	      };
    issued an unwarranted 1520 (multiple assignment operators).


*   During Specific Walks we were inhibiting inference, as too many
    undeserved warnings seemed to ensue from some inferences, especially
    string-related inferences.  We have fixed a number of conditions that
    were giving us problems and we now track separately the buffer length
    and the string length of char * variables.  This gives us a marked
    improvement in our ability to analyze strings.  It also allows us to
    retain full value inference during Specific Walks.
    To revert to the old policy use the option +fii (Inhibit Inference
    during Specific Walks).

*   The Unreachable warning (527) now identifies the token which can't be
    reached.

*   The construct asm { ... } did not support balanced internal braces

*   We were not issuing the 730 Informational (Boolean argument to
    function) when false or true were passed to an int.

*   A symbol was added to error messages 133, 785 and 943 to indicate
    the name of the aggregate (if available) that was unusually
    initialized.

*   We were producing a strange diagnostic (Error 1054: template variable
    declaration expects a type) when the typedef name of an untagged
    struct was used as a class template argument.

*   A friend class declaration that references a class template
    specialization is causing a later definition of the specialization
    to complain of an earlier definition.  E.g.
      template< class T > class C {};
      class B { friend class C<double>; };
      template<> class C<double> { };     // undeserved Error 39

*   We were issuing undeserved error messages when a static const
    member of a class template is defined in terms of itself.
    The following example is a reduction of a construct that
    appears in the Metrowerks Standard Libary
     template< int b > struct C { static const int a = C< b>>1 >::a; };

*   Using the -vo option (emit a verbosity message when an option is
    encountered) we did not previously issue a message for the one-line
    error suppression (!e...).

*   We were not always issuing a 970 Elective Note (use of modifier or
    type not in a typedef).

*   We were issuing an Error 206 (internal error) when processing a
    split string (over line boundaries) during look-ahead.  E.g.
	A a( "start \
	      end" );
    could emit a 206 if look-ahead was required in its parsing.

*   We were issuing an undeserved typedef not referenced message
    when the only use of the typedef was in a function-style cast
    notation.  E.g.
      int f() { typedef int I; return I(3); }

*   We were issuing Elective Note "Octal constant used" while processing
    assembly code.

*   -esym( N, X::operator* ) suppressed message N for all operator
    member functions of X.  It was the programmers intention to suppress
    the message only for member operator*.
    This has now been fixed so that the above applies
    only to member X::operator*.  To refer to the set of all operator
    functions use the option -esym( N, X::operator?* ).
    In addition to "operator*" we are also on special alert for
    "operator*=" and "operator->*".

*   We were giving an undeserved complaint when assigning a base class
    member pointer to a derived class member pointer as in:
      class B { };  class D : public B {};
      int D::* x;  int B::* y; ...
      x = y;
    This is legal.

*   We were giving an undeserved error indicating that a function having
    a base class member pointer could not be matched in an overload
    situation.  For example:
      struct A;
      void f ( int A::* );   void f ( int  );
      struct A { int ai; };  void g( ) { f( &A::ai ); }
    would result in a complaint that there was no matching function.

*   Our documentation on the processing of a .BPR (Borland PRoject file)
    indicated that you could define the location of the Borland's
    C Builder using an option such as -d"BCP=C:\program files...
    The comment has been corrected to -d"BCP=C:\\program files...
    That is, the backslashes need escapes.

*   We now deduce that the argument to functions that require that
    their arguments be non-NULL are in fact non-NULL after, of course,
    issuing any required Warnings.  Thus, strcpy( s,"abc" );  if(s) ...
    gets flagged with Info 774, (Boolean always evaluates to true).

*   We were passing custody to a function even though the function
    takes custody flag was off (-ffc).


*************** Version 8.00L 3/31/2003 ***************

*   Fixed a problem which began with 8.00j in which we do not always
    process member function instantiations.  The result was that
    messages that should have been reported were not being reported.
    For example, all our 8.00 versions when examining the following
    code:

    template<typename T> struct A { A() { unsigned n = -1; } };
    A<int> a;

    will dutifully report that n is being assigned a negative value.
    However under some circumstances including the placement of the
    template within a namespace under versions 8.00j and 8.00k no
    report was issued.  The reason was that we misinterpreted the
    function as being library owing to a flag that was set but never
    reset.  If you were to have used the +flf option (process LIbrary
    Functions) then the expected report would have been issued.

*   We were reporting an undocumented Informational message 1780.
    This message has been removed.

*   The #pragma message could be introduced into the preprocessor
    stream (with the -p option in effect) at places where the stream
    would normally be turned off.

*   We were issuing a syntax error (Error 10) for a non-type template
    parameter having an explicit pointer type as the last template
    parameter.  E.g.  template< int * > class A {};

*   We were prematurely instantiating a template (i.e., instantiating
    before the standard required us to do so) and that resulted in
    runaway recursion while processing headers in the boost library.
    Instantiation is now more carefully controlled.

*   When a --e() option is used in an initialization expression
    there was often an unintended inhibition carryover to the next
    expression.  Example:
     int *p = /*lint --e(910) */ 0;   // Note about conversion is suppressed
     int *q;  q = 0;                  // Note still suppressed.
     p = 0;                           // Note not suppressed.

*   A sequence of --e{} options within the same block could produce
    a performance hit. In one instance, through the magic of macros,
    240 macro invocations produced 720 stack pushes that had to be
    examined on the way to producing an error message.
    We now coalesce similar inhibitions in the same scope.

*   The text of message 958 "Padding of __ bytes is required to align
    member ... " has been modified in the case that it is not a member
    that is being aligned.  The word 'member' is replaced by what is
    being aligned.

*   If the name of a friend class is a template name of a template
    being instantiated we were not using the specialization (that is
    being instantiated) as the friend but rather the template itself.
    E.g.
      template< class T > class A { class B { friend class A; }; };
    When this gets instantiated as A<int> we were regarding the template
    A as a friend; we now properly regard A<int> as the friend.

*   We were not always reporting when a template went unused.

*   We were giving an undeserved error 1065 (symbol not declared as "C")
    when a friend function not defined as "C" was found to have been
    previously defined as "C".  E.g.
      extern "C" void f(int);
      class A { friend void f(int); ... };

*   If two different modules contained a declaration of a symbol that was
    identical except that in the first module the symbol was declared
    with an extern "C" we would not notice the discrepancy and we would
    not issue the expected Error 1066.

*   We were not issuing the expected 1763 (Member function marked as
    const indirectly modifies class) in the case of returning an address
    from a member function.  E.g., the following did not issue a 1763
    for member function X::get(int).
      class X { char *pc; char & get( int i ) const { return pc[i]; } };

*   When processing VC7 project files (.vcproj)
    we were producing null options: -u, -d, and -i for
      UndefinePreprocessorDefinitions=""
      PreprocessorDefinitions=""
      AdditionalIncludeDirectories=""
    respectively.  These null options are usually ignored but could
    be a problem if the -split option is in effect.  For this reason
    they are no longer produced.

*   When processing VC7 project files (.vcproj) we did not previously
    translate $(...) within string constants.  We now translate
    strings containing $(...) into %...%.  Thus:
      AdditionalIncludeDirectories="$(Library);$(Utility)"
    is now translated into
      -i%Library%;%Utility%