bugfix80.txt

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

*   We were not handling all the nuances of reference parameters
    for function templates.  For example:
    the following gave an undeserved Error 64 (type mismatch):
      template <class T> void f( T const & );
      void g() { f( "hello" ); }

*   The following gave an Error 36 (redefining A::B from template
    to class):
      struct A { template <class T> struct B; };
      template< class T > struct A::B {};

*   We were instantiating template member functions too quickly and
    too often.  For example:
      template <class T> struct X { void f() { T a; } };
      struct Y : public X<Y> { };
    would result in Error 1080 (definition of Y not in class scope).
    We now follow the standard and do not instantiate a member function
    (of a template) until after it has been referenced.
    To force instantiation of all members of templates you may use
    the option ++template(80).

*   An undeserved Error 115 (struct/union not defined) would be issued
    in the second module of a two module program.  It would be issued
    on the use of a const template class when an instantiation was
    required.

*   The STL Port library uses an unusual macro to form a #include
    which unfortunately contains blanks which we happened to squeeze out.
    We now retain the blanks.

*   We were not supporting template object parameters as dimensions
    of array parameters of function templates.  Thus
      template< unsigned N > void f( int (&)[N] );
    could not be invoked as expected.

*   With multiple (overloaded) function templates and explicit template
    arguments we were not always finding the right template.  Thus for
      template< class U >  void f( );
      template< class U >  int f( int );
      ... int n = f<char>(3);
    we would arbitrarily find f() and issue an error message.

*   We would not properly handle explicit template arguments for
    function template members.  Thus, in:
      struct R { template< class U > int g( int ); };
      R r;
      int n = r.g<char>(3);
    we would treat the '<' following "r.g" as a comparator.

*   The following sequence did not always work.
      typedef B<int> BI;
      template<> void BI:f() {}
    We might report erroneously that f was not a member of B
    if B<int> was not yet instantiated.
    We now force an instantiation regarding this to be an instance
    in which the type must be complete.

*   We could under some circumstances erroneously take identically named
    templates from different namespaces to be the same.

*   We were sometimes not seeing a global scope operator when used
    on something that is supposed to render a type.  For example
    the ::A in the following got confused with the class A in which
    it is embedded.
      namespace X { class A { T<::A::C> t; }; }

*   We were stumbling over the use of __declspec() following the
    start of an explicit template specialization.  For example:
      template<> class __declspec(...) A<...> ...
    This particular combination required look-ahead that was too dumb
    to handle it.

*   We were having problems with the proper identification of the name
    of the template when instantiating a template class from a partial
    specialization.  For example we would issue unjustified 1073
    (insufficient number of template parameters) for the following:
      template <class S, class T> struct C{};
      template <class S> struct C<S,double> { C (); };
      C< float, double > x;

*   We were not supporting all cases of externally defined templates.
    E.g.:
      struct A { template<class T> struct B; };
      template< class T > struct A::B { };

*   We were issuing an unjustified Warning 512 when a symbol declared
    as static was later redeclared as non-static.  For example:
      static void f(int);
      ...
      void f(int n) { ...
    is by now universally recognized as being valid.

*   We were not supporting explicit self-qualification of declared items
    within a class template.  E.g.
      template< class X > class Y { void Y::f(); };
      Y<float> a;
    would result in undeserved Error 1040 (Y<<1>>::f not legal)

*   We would select an explicit specialization over the original template
    when explicit template parameters would indicate that the caller
    intended the original template.  For example, in the following we
    previously would pick the specialization but now we revert to the
    template.
      template< class T, class U > T g( const U& u );
      template< > int g<int>( const unsigned& u );
      ... g<unsigned char>(4000u);

*   We were issuing an undeserved Error 114 (inconsistent definition)
    for a template definition during the 2nd and subsequent modules
    when the template contained an overloaded member function parameterized
    by dependent types.

*   We were getting confused by a member template that could serve as
    a copy constructor

*   An out-of-class definition of a member function of a template
    could cause an undeserved Error 36 (redefining the storage class).

*   We were not reporting that the following call is ambiguous
	void g(int);
	void g(const int &);
	int n;    ...  g(n);    // ambiguous

*   In function overload circumstances involving function templates we
    were employing previously instantiated versions of a function
    template which the standard specifically excludes from consideration.
    This could result in the wrong function being found.

*   Error suppression options were not properly employed when function
    and template definitions were saved for later processing.  For
    example, the 452 was not being inhibited in the function f() below.
	class A {
	    //lint -e{452}
	    void f() {}
	    int n;
	    };

*   We were not finding some of the source files in a .vcproj file.
    Specifically we were not finding files within more that one filter.
    Thus we would not find the RelativePath in the following:
    <VisualStudioProject> ... <Files> ... <Filter> ... <Filter> ...
	<RelativePath> ...

*   We now support the Borland project files (extension == .BPR)
    This is an XML oriented description similar in principle to
    the .vcproj files of MS .net.  This allowed us to leverage off our
    prior work.


*************** Version 8.00i 9/11/2002 ***************

*   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 a 434 (white space ignored after //) within a C
    style comment.  The message is not needed within comments.

*   We were issuing an undeserved 39 (Redefinition of untagged unions)
    and 407 (Inconsistent tag in the case of untagged structs) when
    two identical such aggregates were nested within separate structs,
    the +fct flag was set, and the language was C.

*   We were not making all possible deductions when the result of
    a relational was being compared with a value.  For example, we
    did not catch the divide by 0 inherent in:
      if( (n == 0) == 1 ) return 100/n;

*   Unix-lint style comments can now be placed in macros such as:
      #define NR /*NOTREACHED*/

*   Lint comments would find their way into pre-processor output
    when this was not warranted.  For example:
      #if 0
      /*lint -e777 */
      #endif
    would be OK under normal linting conditions but when the -p
    (pre-processing flag) was used, the lint comment would wind
    up in the output.  This has been fixed.

*   XML (using env-xml.lnt) output had two problems.  -append'ed
    information was not being incorporated within the message text.
    Also #pragma message was producing non-xml output.  The latter
    was fixed by using the -pragma(message) option in env-xml.lnt

*   It was possible for sequences of the form:
      /*lint -save ... */ ... /*lint -restore */
    to lose synchrony (during look-ahead for example) with the result
    that errors were not being inhibited when they should be.  This
    would commonly occur by using -emacro.  This has now been fixed.

*   We were giving an undeserved 545 (Suspicious use of &) when
    an array was passed to a template object parameter (typed pointer).
    E.g.
      template <char *p> class X { /* ... */ };
      char a[10];
      X< a > x;

*   We were not supporting function-like macro invocation where the
    name of the macro was separated from the following '(' by a comment

*   We were not finding the "f" in the following example:
      namespace A { void f(); class D; }
      class A::B { void g() { f(); } );

*   We were not finding B (the template argument to X) in the following:
      template <class T> struct X{};
      struct A { struct B; };
      struct A::B: public X<B> { };
    In general, classes defined out of the context in which they were
    declared would cause confusion.

*   We no longer issue the memory leak message (Warning 423) in
    catch blocks parameterized by std::bad_alloc

*   User-defined operator new() functions were being regarded as
    possibly returning NULL.  According to the standard this should
    only be presumed if the exception specification is the vacuous
    "throw()".  Of course, it will also be assumed if the +fnn
    flag is set.

*   We now support the variable macro argument convention as defined
    in the C99 standard.

*   We no longer give a 953 (variable could be declared const)
    for references.

*   We were issuing missing-const messages for virtual functions which
    is inappropriate because one interface must stand for several
    implementations which may not even be in evidence yet.  We now
    suppress the following messages for virtual functions:
      1746 (parameter could be made const reference)
      818 (pointer parameter could be made pointer to const)
      1764 (reference parameter could be made const)

*   In .dsp files the test for string equality was case sensitive.
    It is now case insensitive.  E.g.
      CFG=Release
      !IF "$(CFG)" == "RELEASE"
    now is regarded as true.

*   We were issuing Error 303 (String too long, try +macros) when
    +macros would not do any good.  This of course could be quite
    frustrating.  We now diagnose these cases and issue a different
    String too long message (326) which does not mention +macros.

*   We were placing some template storage into a wrongly parameterized
    region with the result that we could not create a string longer
    than about 1000 characters.  This has been fixed so that the maximum
    string is 4000 characters and can grow with +macros.

*   A template that was being instantiated as a result of a sizeof
    operation could produce undeserved 1762 messages (Member function
    could be made const).

*   During each pass (except the first) we inadvertently left one
    additional file open and as a result the number of passes
    become limited by the number of files that could simultaneously
    be open.

*   The representation of a (non-static) member function call
    used in the reporting of messages during Specific Walks was
    marred by an off-by-one error.  This would also occur during
    verbosity messages showing the logging of Specific Calls (-vc)
    and the initiation of Specific Walks (-vw).

*   Our value tracking of data members was being overly influenced by
    values obtained as the result of Specific Walks leaving a false
    hit rate of too high a level.

*   When a function pointer was passed to a function template we were
    not able to match a reference in the parameter list of the function
    with a template parameter in the parameter list of
    corresponding parameter of the function template.  E.g.:
      template< class T1> void f( float (*x)(T1) ) { }
      float h( int & );
      ...  f( h );

*   When a function template is declared after a function by the same
    name we were not allowing explicit template arguments to be used
    with the name.  E.g.
      void f( double );
      template <class T> void f(int) { }
      void g() { f<int>( 0 ); }

*   We no longer issue message 429 (Custodial pointer has not been
    freed) in catch blocks parameterized by std::bad_alloc

*   We no longer report on the use of // in a C module when the
    strict ANSI option (-A) is given since C99 now supports this form
    of comment.  To obtain the old behavior use -A(C90).
    You may also use +e950 to obtain the check.