bugfix80.txt

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

*   We now recognize namespace std by default (i.e. without an explicit
    'using namespace std;' statement) when the -cgnu option (the option
    to specify gcc as the compiler) is given, to conform with the
    expectations of that compiler.


*************** Version 8.00h 6/25/2002 ***************

*   An instantiation of a template bearing an inline function
    within a class member function could cause unqualified name lookup
    to go awry.  In the following s was not found.
    template <class T> struct A
	{ int s; void f() { s = 0; } };
    struct B { void g( void ); };
    void B::g( void ) { A<int> x; }

*   Message 1053 (function cannot be distinguished from another) is
    now accompanied with the minor type differences leading to the message.

*   We were not producing any message when a declaration of a function
    declared the function to be inline whereas a prior definition of
    the function did not indicate that it was inline.

*   We were not recognizing an operator+ after it was defined as a
    friend function of a template specialization X<t>.  We would
    recognize operator+ in the first module that instantiated X<t>
    but not in subsequent modules.  This was because we were not
    reactivating friend functions declarations for subsequent modules.

*   We were not processing Visual Studio 6.0 project files (.dsp files)
    as well as we should.  In particular options appropriate to only
    a single module were being triggered in the order of appearance
    in the .dsp file.  The result was that these options came after
    the module name which was too late to be of any good.

*   We were processing .vcp files as if they were .vcproj files
    rather than as .dsp files.

*   We were not reporting when the address of a (non-reference) parameter
    was being returned.

*   We were not producing declarations of static functions when the
    -odi() option was used.

*   We were not allowing blanks within the -e{...} option.

*   We no longer give message 944 by default during specific walks

*   We were giving an undeserved Error 58 (bad type) when comparing
    ptr-to-member's

*   We were giving an undeserved 1764 (reference parameter could be
    declared const) when the reference parameter (r) was used in the
    following way:   r.*x = expression;

*   A pointer used on the left-hand side of a ->* operator would
    not get credited with an access.  Thus the expression
	(p->*pmf)(arguments);
    would not be sufficient to suppress Warning 550 (symbol p not
    accessed).

*   We were issuing an undeserved Info 1764 (Reference parameter
    could be made const) when its only use was in the call of a member
    function through a pointer to member function.  E.g.
	void f( C &r, void (C::*f)() ) { (r.*f)(); }
    would result in a 1764

*   A parameter declared Pointer-to-member-function would receive an
    unjustified 818 (pointer could be made const).

*   We would report an 'inconsistent structure definition' for a class
    within a lob that contained a template function member.

*   We were issuing an unjustified Corrupt Lob (Error 304, code 26)
    when a template function was called where the function sprang
    from a partial specialization.

*   We were issuing an unjustified Error 126 (inconsistent structure
    definition) when processing 2 or more .lob files that were produced
    by C (as opposed to C++) modules that contained nested struct's.

*   We were issuing an unjustified Error 126 (inconsistent structure
    definition) when processing 2 or more .lob files that contained
    untagged enum's that were not identical.  Our flaw was that we
    were making them identical when they were not and reporting the
    inconsistency at lob time.

*   We were looping on the following constant: 0.0e-999999
    In general, whenever there was a 0 value with a huge exponent
    we could loop.

*   We were giving an undeserved 304 (Corrupt Object file) code 28
    when linting a lob that contained a class that had both a function
    and a function template by the same name.  Such a condition prevailed
    in OLE.


*************** Version 8.00g 4/10/2002 ***************

*   You can now suppress message 126 with an -esym.

*   We no longer append a useless blank to "module" verbosity message.

*   Enhanced the env-xml.lnt file so that xml escapes would be employed
    for xml meta-characters.

*   Added the +fet flag (Explicit Throw) flag.  See readme

*   We were failing to deduce that after a successful test for
    x > 3 that x could no longer be 0.

*   An 'improvement' in our unqualified name lookup introduced in
    8.00f had a slight bug that would evidence itself when a function
    defined outside of its namespace was declared to return a pointer
    or reference.  E.g.
       namespace X { struct S { int *f(); }; }
       int *X::S::f() { int a; ...  }
    a would be considered defined within namespace X.

*   We were issuing an undeserved Error 64 when initializing a reference
    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.