bugfix80.txt

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

    with a reference to a type that differs in some way from, but could
    be converted to, the target type.

*   We were not finding all source file names in .vcproj files.
    We were triggering off the attribute: name = "Source Files";
    but this is not that reliable as other names can be used.  We now
    trigger off extensions.

*   We were not properly truncating casts during value tracking.
    Thus information losing casts would retain their original values.

*   We were giving an undeserved Error 64 when an attempt was made
    to assign a pointer to a bool.  This is perfectly valid code and
    now draws only the usual implicit conversion messages.

*   We were not handling the .NET keywords __if_exists() and
    __if_not_exists() properly.  Although referred to as statements
    it seems they can appear anywhere in the source code, within
    classes, within initializers, etc., and not just within code blocks.

*   Unqualified name lookup in a constructor initializer would create
    a problem if the namespace depths become deep enough.  E.g. in the
    constructor definition:
       A::B::C::X::X() : B::X(3) {}
    where A, B, and C are namespaces, we would not find B.
    this had worked in patch levels prior to 8.00f.

*   We were converting bools b1 and b2 in the following expression to int.
      predicate ? b1 : b2
    According to the standard the result is a bool not an int.

*************** Version 8.00f 3/18/2002 ***************

*   We were not rewalking (in subsequent passes) class member functions
    defined in the class.

*   We were not rewalking instances of template functions in subsequent
    passes.

*   We were not rewalking template member functions in subsequent passes.

*   When there is a repeated definition of a template specialization
    as in:
	template<> class A<long> {};
	template<> class A<long> {};
    we correctly issued an Error 39 but the location we cited as being
    in conflict was the new location not the old location.  This has
    now been fixed.

*   We were sometimes not finding the correct namespace when a global
    scope operator was provided.  e.g.
      namespace A { class X {}; }
      namespace B { namespace A { class Y{}; } class Z { void f(); }; }
      void B::Z::f() { ::A::X n; }  /* we can't figure out ::A::X */

*   There was no way for a user to totally suppress #error messages.
    Now if you give the +fce (continue on #error flag) AND suppress
    message 309 with -e309 you will continue on as if nothing happened.

*   The flag +fdh (add .h by default for #include "name" where name does
    not have an extension) previously did not work with Unix systems.

*   Our unqualified name lookup has been improved so that we can pick
    up identifiers not only in the namespace bearing a function but
    in any containing namespace as well.  For example we were not
    finding the "i" in the following return statement:
	namespace A { int i; namespace B { int f(); } }
	int A::B::f() { return i; }

*   We were issuing a 304 (Corrupt Object file), code 23 for a template
    that was involved in an expression where the template arguments were
    somewhat intricate.  The smallest example causing the problem was:
	template <class E> class V { typedef V<E> y; };
	typedef V< V<int> > B;
	typedef V< V<B*> > C;
	B b;

*   We were issuing an undeserved 429 (custodial pointer not freed)
    during a specific walk of a function that was handed a pointer
    that was custodial in the caller.

*   Given two consecutive calls with partial lists of explicit template
    arguments could result in the wrong function.  E.g
      template <class T, class S> T f(S);
      double y = f<double>(0);    /* ok uses f<double,int> */
      long x = f<long>(0);        /* bad, still uses f<double,int> */

*   We were looping during the delete of class A that contained a
    member typed T<A> which in turn had a reference to A as a member.

*   When -emacro was applied to a macro which began a default
    argument the error suppression would not take place.  E.g.
    //lint +e1924 -emacro(1924,M)  warn about C style casts except in M
    #define M (int) 10
    template< int k = M > class A { int x[M]; };
    A<> a;    /* Issues a 1924 anyway */

*   We were occasionally issuing an undeserved Error 40 when processing
    member declaration within a class template.  The declaration includes
    the sequence:
	    ... typename qualified-name declarator;
    The Error 40 was somewhat random and 'typename' was necessary.

*   We were not allowing a function (declared to return void) to
    return an expression typed void

*   volatile variables are not assumed to hold values assigned to them
    with probability one.  Variables that are const volatile and
    initialized are not assumed to hold the const variable property.

*   We now support template nontype reference parameters and
    pointer parameters semantically and not just syntactically.

*   a MISRA rule 42 warning (avoid use of comma operator) was not
    suppressed in the top-level for clause.

*   We were issuing an unjustified 957 (Function defined without a
    prototype in scope) when a static member of a namespace was being
    defined as in:
	static void N::f() {}

*   We now support template member operators.  E.g.
	template <class T> class C {
	    template<class U> int operator==(U); };

*   We were giving an undeserved Info 768 (global member not referenced)
    for a template member even though the member was referenced in
    an externally defined function member.

*   We were not handling complex macros in the #include syntax.
    For example,
	#include macro(name)
    where macro evaluates to an angle-bracketed expression.
    This had been working prior to 7.50o.

*   We were not giving a divide by zero warning when a float was
    being divided by an integer.

*   We are now processing VC7 project files (extension .vcproj)
    producing an equivalent .lnt file (similar to .dsp).

*   We now support the Microsoft __if_exists and __if_not_exists
    keywords introduced with .net

*   We are getting an undeserved Warning 650 (Constant out of range)
    when a bit field contains an enumeration and is compared with
    an enumerator even though the +fbu (bitfields are unsigned) flag
    has been set

*   The Gnu reduced variant of the ?: operator, e.g.
	a = f() ? : -1;
    is supported.

*   The Microsoft attribute designation using [ ... ] before a
    type specifier is supported.

*   We were issuing an unjustified 1001 (X must be struct or class)
    for the following:
	template< class T > class A : public T::X::Y {};
    The message was benign as it did not prevent us from instantiating
    A properly.

*   We were issuing an unjustified 1070 when processing ATL (the Active
    Template Library).  The cause was traced to our inclination to
    unnecessarily instantiate template arguments.  Thus in:
	A< B<x> > a;
    there is normally a need to instantiate A< > with the appropriate
    type but not B< >.

*   We now support unnamed template parameters as in:
	template< class = int > class A {};

*   We now support template template parameters.

*   We now arbitrarily break template recursion and give a message
    indicating we are doing same.  The reason for this is that it
    is possible to define a recursive template as in:
	 template <class T> class A { A< A > x; };

*   We were not handling all uses of @ for the Cosmic compiler.
    In particular we were not handling @ as an introduction to a
    modifier.  For example:
	char * @near f();

*   We were issuing an unjustified 793 (external count exceeded ANSI
    limit) counting statics as externals

*   A complex initializer involving a template-id (i.e. an
    expression of the form: name< ... >) could trip up our
    look-ahead.  For example:
	 C x( NS::foo<int>() );
    was not parsed correctly because the look-ahead to break
    ambiguity involved a template-id.

*   Under some circumstances, when a member function of a template class
    was defined out of line we were not recognizing the function
    as a previously declared member.  The class had a non-type parameter
    and the function parameter was of the form C<I> and the out of line
    declaration used a slightly different form for the parameter than
    the inline.  E.g.
	 template< int I > class C { void f(C<I>); };
	 template< int I >  void C<I>::f(C)  {}
    This occurred in the MS header atlbase.h for VC7.

*   If two successive template parameters have the same name we would
    crash.  E.g.  template< class T, class T > void f();

*   When a template parameter contained a dependent type we could crash.
    E.g.
	 template< class T, T::M (*pf)() > ...
    Such a construct occurs in dxatlpb.h for VC7.

*   Our flag +fbu (bitfields are unsigned) was not being honored in the
    case of enumerations.  E.g. the following gave an unjustified constant
    out of range message.
	 //lint +fbu
	 enum E { a, b, c };
	 struct S { E m:2; } s;
	 void f() { if(s.m == c); }


*************** Version 8.00e 11/21/2001 ***************

*   Introduced Warning 686 suspicious option (unbalanced quotes)
    to cover what could be an almost undecipherable situation in
    processing lint options.  E.g.
	-i"C:\lint\"  std.lnt ...
    was parsed by the command processor to produce
	-iC:\lint"  std.lnt ...
    Warning 686 at least warns of the dangerous condition.

*   We now treat @ within a declaration specifier as being something
    that gets ignored with a Warning 431.  This enables compilers with
    syntax that resembles:
	@interrupt void f() { ... }
    to have a chance of working correctly.

*   We were issuing an undeserved 1928 (base class not on initializer
    list) when the base class had no constructor to begin with.

*   Added the ability to convert pragmas and/or preprocessor lines
    into macros.  This was needed by the ByteCraft compiler.

*   We were getting exceptions in template processing.  This would
    occur in template wrap-up activity when an instantiation of one
    function would trigger the instantiation of a template class.

*   When a base class within a template was originally a dependent
    type then it should not be searched for names during unqualified
    name lookup.  Since this is only a recent change in the standard
    and since most compilers do not support this change it is controllable
    via option: ++template(40)

*   We were issuing an unjustified Error 1050 (Expected a template
    argument list) while processing the Microsoft Standard Template
    Library.  We were finding the name "interator" in the base class
    iterator<int> which is not justified by the standard.  This was
    interfering with our finding class iterator.

*   We were issuing an unjustified 1549, 1550 and 1560 (exception thrown
    was not declared) within a function which had no exception
    specification and therefore is declared to throw any exception.

*   We were issuing an unjustified 1775 (catch block does not catch
    exception) when a function with no exception specification was called
    from within the corresponding try block.

*   A template function if the form:
    template< class T, class U > void f( const A<U> & );
    was not being matched by an argument of the form const A<type> &.

*   a user semantic option within a template could cause a crash.
    E.g.  template<class T> class A { /*lint -sem( a, custodial(1) )*/ };


*************** Version 8.00d 10/29/2001 ***************

*   We were issuing an undeserved 777 for the following:
    if( (x > 0) == (y > 0) ) ...
    where x and y are floating point numbers.

*   We now allow a variable number of arguments when a macro is
    defined using the -dname()=... form.  For example: -dasm()=0
    followed by:
	    n = asm( "mov a,3", "add b,a" );
    would work fine.

*   Allow unsigned integer constants for bit addressing.  E.g.
    a.0x3 = ...

*   We were issuing an undeserved 765 (could be made static)
    for a function whose only declaration is within another function.

*   rw_asgn(to,from) and ppw_asgn(to,from) did not work unless
    the from keyword was enabled.  For example to assign the meaning of
    "_to_brackets" to "IGNORE" you had to first enable the former as in:
	+rw(_to_brackets)  +rw_asgn(IGNORE,_to_brackets)
    This first option is no longer necessary

*   When the height of messages are 4 (-h...4) We we