bugfix80.txt

PC_LINT8_w,经过测试

    argument list is called relying on an implied this could
    result in an undeserved 1032 (member needs an object).
    E.g.
      struct A { template<class T> void f();
                 void g() { f<A>(); /* 1032 */ };
    SRGS

*   An option of the form -e{...} within an inline function within a
    library header (but not within a class) would by default not
    turn itself off at the end of the function.
    AAFB

*   If a variable known not to be 0 is then determined to be < 1
    or > -1 we erroneously deduced that it could be 0.
    INKV


*************** Version 8.00s 8/18/2005 ***************

*   A recent fix in 8.00r created a problem in the interpretation
    of scoped names within templates.  Before that fix we had interpreted
    T::N in the following example
        template< class T > class A { T::N x; };
    as a type; this is not standards conforming.  The standard requires
    the use of the keyword 'typename' before the 'T::N' and 8.00r
    enforces this rule too strictly. Many compilers were all to happy
    to accept T::N as a type without a preceding 'typename'.
    The current fix deduces when such scoped names can only be types,
    but issues a new Informational message (1710) to alert the user.
    ICTM, 8/11/05

*   A recent 'fix' involving a parameter typed as reference to a
    pointer to function had the nasty side-effect that
    we began not to recognize that a pointer so passed in could
    be initialized.  This has been refixed correctly.
    PPFI, 8/12/2005

*   We were complaining (Warning 504) that the right side of a
    shift was not parenthesized even when the operation in question
    was the assignment shift '<<='.
    USNU, 8/12/05

*   Added a warning message for the use of +cpp(.C) in a Windows
    environment suggesting the use of -fff.
    CUCE, 8/12/05

*   When a C++ module containing a using declaration at file scope
    such as ...  using std::printf;
    and is followed by a C module with an identically named function
    at file scope such as ... void printf( ... );
    undeserved type clashes were being reported.
    CMUL, 8/15/05

*   Added the -Aidentifier=state form of assertion equivalent to
    -A#identifier(state)
    PFAO, 8/16/05

*************** Version 8.00r 8/5/2005 ***************

*   We were issuing a spurious 151 and 1054 for the following
      template< class T, int b > struct X;
      template< class T > struct X< T, 1 > { X(); };
      namespace N { struct G { struct H { X<H*,1> hx; }; }; }
    The message occured while generating a copy constructor when
    instantiating X<H*,1>.
    NSNC, 11/16/04

*   We were interpretting square brackets intended to represent an array
    dimension as a .NET attribute.  E.g.
      void f( unsigned [10] );
    APAR, 12/2/04

*   Strong (typedef) types defined in classes and namespaces and
    templates are now appropriately qualified when presented as
    part of error messages.
    SCTD, 12/3/04

*   Template class names will no longer use default template arguments
    in their presentation in messages.  E.g., given
      template< class T, class A = Allocator > class S;
      S<char> x;
    A diagnostic about the type of x will use the designation "S<char>"
    and not "S<char,Allocator>"
    SLTC, 12/6/04

*   Added support for the Misra II diagnostic (at most one break statement
    used for loop termination)

*   There were some subtleties in the processing of C99 designators.
    In particular we could not handle designator lists of length
    more than 1.  E.g.
      struct A { int y; int x[4]; } a[3] = { [2].x[1] = 3 };
    can now be processed successfully.
    DNJG, 12/13/04

*   In our messages that reference types within a C program
    the Keywords 'struct', 'union' and 'enum' are almost always useful
    as prefixes for aggregate names (known as tags).  In the past
    these keywords were sometimes but not always provided.
    No change was made for C++ programs.
    CNCC, 12/10/04

*   We now report when a '{' is encountered within an initializer
    at a location where a scalar value was expected.
    EBNS, 12/14/04

*   Dependent names were undeservedly being equated making overload
    function call resolution in some cases problematic.
    TMD, 12/14/04

*   It was possible to loop while processing the size_t class template
    from the Boost MPL library.
    OAIH, 12/15/04

*   We were losing information about the size of a (nul-terminated) string
    in an array.
    CVLV, 12/17/04

*   We were complaining (Elective Note 971) about the use of char
    without 'signed' or 'unsigned' when the fdc flag (Distinguish
    plain char from char) was turned off.  Clearly the note is
    not appropriate in this case.
    CDWS, 12/20/04

*   A function template containing a function parameter whose type
    is a qualified-name whose nested-name-specifier is dependent
    could result in a spurious 1024.
    E.g. template< class T > void f( T::M, T );
    ...         struct A { typedef double M; };
    ...         f( 3.5, A() );             // undeserved 1024
    SNDC, 12/20/04

*   An undeserved 1039 was issued when there was a textual inconsistency
    in a type that was used in the prototype of a member function
    declaration and its corresponding definition. E.g.
      template< class T > struct A { };
      template< class T > struct B { typedef A<T> M; void f(M); };
      template< class T > void B<T>::f( A<T> );  // undeserved 1039
    DTOF, 12/22/04

*   We issue an undeserved 1763 (member function marked as const
    indirectly modifies class) when the address of the member function
    is passed to a non-const function.  E.g. B::g in the example below
    does not modify its class even indirectly.
      struct B;
      typedef void (B::*PMF)(void) const;
      struct A { PMF &h(); };
      struct B
          {
          A a1;
          void f()
              { a1.h() = &g; }
          void g() const {}
          };
    12/27/04

*   A macro with arguments but separated from its argument list
    by a lint-comment would not invoke the macro.  E.g. max(a,b) in:
      max /*lint -restore */ ( n, m )
    would not be expanded.  Users would not normally type such a thing
    but through the workings of -emacro such a construct could be
    generated.  This has now been fixed.
    LCIE, 12/27/04

*   Passing the address of a member function resulted in our thinking
    that the member function deeply modifies the this object and
    we were issuing an undeserved 1763.

*   We now suppress message 970 (using a raw type outside of a typedef)
    in the case of a bit field to bring this into conformance with
    Misra 2.
    BTAB, 1/4/05

*   We had not been supporting the C99 feature of allowing an incomplete
    array (i.e. one without a dimension) as the last component of a struct.
    IASE, 1/4/05

*   We were unable to coherently display the type for U<list>
    where U is a template template parameter.
    TPSB, 1/6/05

*   We did not report on a failure to deduce all template parameters
    for a function template.  E.g.
      template< class T > int f(int);   int n = f(0);
    DTDF, 1/11/05

*   We were failing to deduce the correct template when an actual
    argument to a function template was a template specialization and
    the corresponding parameter involved the use of a template template
    parameter.  E.g.
      template< template<class> class U > int f( U<int> );
      template< class T > struct A { };
      A<int> a;
      int n = f( a );     // deduce that U is A
    CDTT, 1/11/05

*   We were not complaining about the lack of certainty of variables
    after exiting a loop.  E.g.
      n = 1;
      for( i = 0; i < 10; i++ )
          ;
      if( n == 1 )            // No Info 774 (Boolean is always true)
    AFLI, 1/31/05

*   We were instantiating member functions of class templates even
    though those members were not referenced for a given class template
    specialization.
    UMTI, 2/8/05

*   We were sometimes taking the wrong effective parameter list
    when instantiating a member function of a partial template
    specialiation which could give unpredictable diagnostics and
    could possibly cause looping.  The following example caused
    looping:
      template <class T> struct A { };
      template <class T> struct A<T *> { ~A(); };
      template <class T> A<T *>::~A() { }
      A<int *> a1;        // loop

*   When deducing the type of a template parameter from an argument
    of a call to the template we did not always transfer const/volatile
    qualification of the argument to the type being deduced.
    In the following, g(b) should match the template but were rejecting
    it (Error 1025) because we didn't deduce T to be const.
      struct A { int b[10]; int f() const; };
      template< class T, unsigned N > int g( T(&)[N] );
      int A::f() const { return g(b); }  // undeserved Error 1025
    OFRA, 2/8/05

*   An infinite loop could result at template wrap-up time (the
    time when we are attempting to compile function members of
    instantiated templates.  The conditions require a partial
    template specialization.  Example:
      template< class T > struct A{};
      template< class T > struct A<T*> { ~A(); };
      template< class T > A<T*>::~A() {}
      A<int *> a1;
    WPTI, 2/8/05

*   We were issuing an Elective Note 957 (definition given without
    a prototype in scope) for a function template.  It was argued
    that whereas function definitions should always have prototypes
    in scope that argument is harder to make with function templates
    which often serve more as a declaration than a definition.
    FDNP, 2/11/05

*   When a member function calls a non-const member function we
    didn't completely drop value information for non-static data
    members resulting in undeserved complaints.  E.g.
      struct A
          {
          int a;
          int g() { a = 0; f(); return 10/a; }  // undeserved "divide by 0" msg
          void f() { a = 1; }
          };
    COCT, 2/15/04

*   We did not always force type completion at places required by the
    standard.  In the following example the use of i with the
    operator == should force instantiation making the use of the
    operator quite legal.  Instead we gave a "bad type" message.
      template< class T > struct C;
      template< class T > struct I { bool operator==( const C<T> & ); };
      template< class T > struct C { C( const I<T> & ) {} };
      int f( I<int> & i ) { return i == i; }  // unjustified bad type
    ORRI, 2/18/05

*   We would report an error when calling a reference to a function
    pointer.  E.g.
      typedef void (*PF)(int);
      void f( PF & pf )
          {
          pf( 0 );        // undeserved error
          }
    RFCE, 2/16/05

*   When a volatile variable is acquired a value we normally reduce the
    certainty of its retaining that value.  But this was not happening when
    values were acquired in other ways such as through value inference.
    IOVV, 2/21/05

*   We were getting caught in a recursive loop when a template was
    using a dependent instance of itself as a base class. E.g.
      template< typename N1 , typename N2  >
          struct C : C< C< N1,int >,  int>
              { };
    Such a construct was employed in the Boost Library.
    HEBM, 3/12/05

*   We were issuing undeserved Error messages while processing
    objects of dependent types (within templates).  For example:
      template< class T > void f() { A<T> a;  a == a; }
    would draw a complaint that a was inappropriate for use with the
    operator==().  This would be fine if it were given at instantiation
    after it is decided that A<T> has no such operator but is not
    appropriate after just seeing the template.
    UCDG, 3/15/05

*   There is a finite limit (though very large) to the length of a
    template id (for the purpose of error reporting).  The limit still
    exists but can be increased by using the +macros option.
    ETEF, 3/17/05

*   We sometimes do not deduce the correct type when the parameter
    of a function template has a dependent type of the form:
    D::name const.  In particular the 'const' drops off. E.g.
      template <class T> struct A { typedef T u; };
      template <class T> int f( typename A<T>::u const & );
      int i = f<int>(0);          // spurious 1058
    QCXD, 3/29/05

*   We did not tolerate simultaneously a function and a function template
    that took identical arguments:
      template <class T> int f( int, double );
      int f( int, double );   // legal
    FOFT, 3/28/05

*   Dependent types in base clauses have led to infinite loops
    (unjustifiably).  In particular the Boost library contained several
    such constructs.
    DLIL, 4/4/05

*   Upgraded our Misra 2004 support by allowing comments following
    null statements and allowing (null) macros before a null statement.
    MTNS, 4/14/05

*   We added support for the MISRA "underlying type" construct and
    adjusted the au-misra2.lnt file accordingly.

*   Fixed a memory leak that affected programs containing lots of do
    statements.