bugfix80.txt

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

*   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.

*   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