bugfix80.txt

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

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

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