bugfix80.txt

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

    ** This is our Bug Fix list for Patches to **

       **  PC-lint / FlexeLint Version 8.00 **


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

*   We now have minimal support in place for the Variable Length Arrays
    of C99.

*   Added support for the #pragma dictionary option of VAX C/C++


*************** Version 8.00k 1/29/2003 ***************


*   We were issuing undeserved Error messages 64 and 55 while
    processing the prototype of a function template having a parameter
    of a dependent type and a default value of a known type.
    Such constructs appeared in xstring, streambuf and istream within
    the Microsoft library.

*   We were issuing an Error 39 when we encountered an old-style
    class template specialization (one which failed to be preceded
    by "template<>").  For example:
	class A<int> { ... };
    Though obsolete, this form persists in older code.  We now interpret
    this as a specialization and do not give the message.
    One such construct appeared in xlocale of the Microsoft library.


*************** Version 8.00j 1/23/2003 ***************

*   An inline -sem() option would cause a parsing problem if placed
    just after an inline member function definition.

*   Owing to a recent change introduced in 8.00h, We were no
    longer processing subclasses defined out of line properly.
    The following would throw us:
      struct A { struct B; };
      struct A::B { int f() { return k; }  int k; };

*   We were using the convention that the result of an assignment
    is not an lvalue.  This is ok for C but not for C++ where
    assignment is an lvalue.   We now properly assume an lvalue
    for assignments within C++ modules.

*   We were giving an unjustified 1764 (Reference parameter could be
    declared as const ref) when the parameter was passed to a const
    ref to a plain pointer.

*   Given the declarations:
    void f( int & );  void f( const int & );
    we were reporting that f(10) was ambiguous.  We now correctly
    deduce that the 2nd of the two functions is selected.

*   We were giving an undeserved 1762 (member function could be made
    const) when the member function was returning the this pointer
    as a non-const return value or returning *this as a non-const
    reference.

*   We were giving an undeserved 1762 (member function could be made
    const) when the member function contained an assignment to *this.

*   We were issuing an undeserved 564 (variable depends on order of
    evaluation) for:
      struct A { volatile int n, m; } a;   ...
      ...   a.n == a.m

*   We now support the C99 concept of designators.  For example:
    struct point { int x, y; } P = { .y = 1, .x = 2 };

*   Messages relating to the start of a loop were sometimes placed
    in such a way that they seemed to refer to the statement following
    the loop.  This was causing confusion.  We now employ the correct
    code location and if the statement is past it is simply not printed.

*   We were giving an undeserved 550 (q not accessed) even though
    q was being used in an expression of the form (q->*a).

*   We were giving an undeserved 818 (p could be declared as pointing
    to const) even though p was being used in an expression of the form
			p->*a = 0;

*   In the AdditionalIncludeDirectories attribute of a .vcproj file
    there was a possibility of a "&quot;" appearing as part of a quoted
    string.  This represents a redundancy and is now ignored.

*   In the Microsoft conversion of a .dsp file to a .vcproj file the
    separator character for IncludeDirectories is retained as a comma.
    This is now correctly translated to a semi-colon.

*   We were reporting failure to open a file when an indirect file
    contained more that about 500 files and the --u option was being
    used.  It seems that files were not being closed after being opened.
    Most of these files didn't have to be opened anyway and so it now
    not only operates correctly but is a lot faster.

*   Even though -ftg (don't translate trigraphs) was given we were
    nonetheless quietly processing many if not most trigraphs anyway.
    Now we give appropriate warnings.

*   We were not issuing the Misra complaint (Elective Note 960)
    about the lack of braces for the statement following an else.

*   Complex switch expressions could be misinterpreted as having
    a type smaller than the actual type with the result that
    we could give an unjustified range error when processing
    a case statement.

*   We no longer issue an Elective Note 950 (non-standard construct)
    when a C program contains a // comment unless the -A(C90)
    option has been issued.

*   We were giving an undeserved Elective Note 917 (prototype coercion)
    when a Boolean expression was passed to a parameter that was
    typed with a Strong Boolean type (using C) that was not some
    form of integer.

*   We were reporting in an Elective Note (953) that a label could be
    declared as const.

*   We were not allowing 'typename' to introduce a type within a
    using declaration within a template.

*   We were not properly processing the case when a template was
    instantiated within a member function.  Member names would
    become visible and potentially interfere with the proper
    processing of the template.

*   The partial template specialization did not work properly through
    a typedef or other contexts in which an instantiation was not
    immediately required.  E.g.
      template <class T, class U> class A {};
      template <class T> class A<T,int> {};
      typedef A<double,int> X;
    When X would be instantiated we would find the general not the specific A.

*   We were issuing an undeserved Error 36 when processing a
    specialization of a function template that had a void argument
    list.

*   When the -cgnu option is set we now allow programs to specify
      std::name which picks up name within std:: if there and searches
    the global namespace if not.

*   We were issuing an undeserved 534 (Ignoring return value) when
    employing an assignment operator that was an explicit specialization
    of a template defining the assignment operator.
    This occured when using the COM libraries.

*   We were issuing an undeserved Error 26 (Expected an expression, found
    '>') while processing templates in the Boost Library.  This could
    occur when a dependent type was used as a template subscript
    in a nested type-id.

*   We were giving a redefinition error (39) when an early use of
    a template specialization that did not require instantiation
    was followed by a template definition which was then followed
    by an explicit specialiation which matched the earlier use.
    We were triggering the instantiation prematurely.

*   When a template contains a second template, parameters of the first
    template were not available when the second template was
    instantiated.

*   Names of templates within template definitions and within template
    member definitions were not always being translated from the class
    template to the template class.  For example the return value of f
    within A<int> should be A<int> and not A<<1>>.
      template <class T >
	  struct A { template <class U> A f( A<U> ); };

*   We were issuing an undeserved 1521 (multiple copy constructors)
    when a template could match the prototype of a copy constructor.
    Templates, of course, can't serve as copy constructors.

*   We were not supporting conversions using template constructors.
    Thus the following code reported a type mismatch when b was defined.
      template <class T> struct A { };
      struct B { template <class U> B( A<U> ); };
      A<short> a;
      B b = a;

*   We were issuing unjustified Informational 754 (structure member
    non referenced) for members of template instantiations.

*   We were issuing unjustified Warning 1526 (member function not
    defined) for instantiations of member function templates.

*   When a #include <name> is used where name does not include a .h
    it is possible to have a .h added automatically to the name by
    using the +fdh option.  This feature has been extended so that
    if the name with the .h appended does not result in a found file
    then the original name was used.  This was found to be necessary
    when using the Borland libraries in conjunction with some STL
    libraries.