bugfix80.txt

PC_LINT8_w,经过测试

    ctor-initializer was treated as a constructor whereas it should be
    regarded as a type.
    CNCI

*   The following sequence created a syntax error within a non-static
    member function even though A::m was a legitimate object of class
    type having a 'c' member.  We were confused thinking the intent
    was an address of member operation.
            &(A::m.c)
    CPMR

*   The instantiation of a function member of a class template would
    not parse properly if it contained a function-style cast where the
    name was the unadorned name of the template.  We would complain that
    the result of the cast was a template.
    WNCI

*   We were not giving access permission to nested classes to
    private and protected members of the enclosing class(es).
    NCAE

*   A modification was made to support the non-standard syntax
    of GCC's asm statement.  For example the following is valid
    in GCC:
        asm volatile ( "..." : "..." (foo) )
    The standard does not allow for the volatile keyword and requires
    a single string constant as an argument to asm().
    When the -cgnu option is used we now automatically support the
    non-standard asm syntax.  To obtain the old syntax (perhaps so
    as to find deviations from the standard) and still use -cgnu you
    may follow that option with -rw(asm) +rw(asm).
    GVAK

*   We were not excluding objects, functions and enumerator names
    during resolution of a name preceding the scope operator
    within a class.  Such exclusion is required by the standard.
    E.g.
        struct A { struct B { typedef char C; }; int B; B::C x; };
    Such exclusion is required to drill down and find the right 'B'.
    ECNL

*   When we encountered more than 255 self-canceling esym sequences, e.g.
       -esym(number,name)  ... +esym(number,name) we would crash.
    RECC

*   When a template has a dependent type as a base class
    and the dependent type is some variation of the deriving class
    the potential existed for an infinite loop.  Such a construct
    appeared in boost::mpl::plus.
    DLIL2

*   Single line suppression did not apply to the if, while, and for
    expressions during the Specific Walk.  For example:
        if( some-expression )  //lint !e413
            {
            ...
    would suppress a 413 on the given line during the General Walk
    but would not inhibit a 413 during a Specific Walk.
    SLSE

*   When a class name is qualified by itself and used as a nested
    name specifier (E.g. A::A::x) the 2nd "A" will no longer be
    recognized as a construct or name but as simply the class itself.
    In the example this would be equivalent to A::x.
    AISN

*   The GCC __null (for null pointer) is now supported automatically
    with the use of the -cgnu option.  As a reserved word __null can
    be activated for any compiler.
    BTNP

*   When a nested-name specifier contained the name of a member function,
    we would issue an Error even though further searching might find
    a perfectly suitable qualification at some lower priority scope.  Eg.
        class A { void std(); std::B x; };
    is valid if std contains B.
    CMFS

*   We now take into account that external calls could modify static
    variables.  Eg.
        int n;
        int g() {n=0; f(); return 100/n; }
    A divide-by-zero message is undeserved if f() modifies n.
    FMSV

*   We issue a spurious 1078 for
        namespace N { template< class T > struct A{ }; }
        template< class T > struct A : N::A<T> { };
    We erroneously retrieved the ::A rather than the N::A as the base class.
    UTDC

*   During heavy usage of look-ahead we could issue an Internal Error 1214
    VROS

*   We were not handling C99 array designator inversions such as:
        int a[2]    { [1] = 1, [0] = 0 };
    DMAO

*   We reduce the certainty of our knowledge of auto variables when
    entering a loop because possible changes within the loop that
    have not been seen yet.  This does not apply to const int variables
    for obvious reasons.  But it erroneously did apply to const pointer
    variables.  We now retain our certainty of all const variables.
    CRNC

*   The current instantiation was not always recognized as such while
    instantiating a template.  As an example:
        namespace N
            {
            template< class T > class C
                {
                class D
                    {
                    C e();
                    };
                };
            }
    The "C" within class D can either be suffixed with a "<T>" or not
    and both would refer to the current instantiation and not to the
    template named C.  If the "<T>" were absent as in the example we
    would mistake the "C" for the template and later claim that the
    template was not defined.
    CINC

*   We were issuing an undeserved Error 36 (redefining the storage class
    of A) with the following friend declaration:
        template< class T > friend class A;
    when the definition of A<T> was subsequently found.
    SCFT

*   We were not handling an elaborated type specifier within a 'new'
    expression in a flawless fashion.  For example:
        A * a = new struct A;
    would be greeted with Errors 84 and 64.
    ETNE

*   We were issuing a spurious 1058 error when returning a class
    that had a copy constructor whose parameter was ref as opposed
    to const ref.
    NUIC

*   When an R-value is used as an implicit non-const class parameter
    in a call to a member operator function we issued an undeserved
    Error 1058.
    RMBI

*   When argument-dependent lookup found more than one associated
    namespace only the first was considered.
    FAAS

*   In an initializer expression for a static data member we would
    issue an undeserved access violation when a protected base member
    was accessed.  E.g.
        int C::m(B::f());
    is OK if B::f() is protected provided B is a base class of C.
    ECSM

*   Formerly dependent base classes should not be employed during
    unqualified name lookup.  For some cases formerly dependent base
    classes were so employed.  These were relatively obscure cases
    involving non-template temploids such as nested subclasses of
    class templates.
    INL4

*   We were not recognizing locally formerly dependent base classes
    within a function template as such.
    OPFB

*   We now support C99's compound literal.  Eg.
        ( int [3] ) { 6,5 }
    is an array of two int's initialized as given.
    CPLS

*   Argument deduction would erroneously fail to select the partial
    specialization in the following:
        template< class T, class U > struct A;
        template< class T > struct A < T, const T & > { ... }
        typedef int const B[2];
        A< B, B& > x;
    QAAE

*   The dimension of an array needs to be determined by its highest
    index when using C99 array designators.
    HIDD

*   Added C99's hexadecimal floating point constants.
    HFCC

*   We were not triggering argument dependent lookup in all cases
    that we should have.  In particular if a name for the function
    was found we would not trigger it.  The standard indicates
    several conditions in which ADL would be triggered such as
    when the initial search finds unqualified ID's at the global scope.
    ADLC

*   The following excerpt from the boost headers produced an infinite loop.
    The problem was traced to an overexuberant search of dependent
    base classes.
        template <typename T> struct A        : A<T*>{};
        template <typename T> struct A< const T > : A<T>
            {
            int f();
            };
    DBDT

*   We no longer issue Warning 528 ('not referenced') for static
    inline functions found in headers.
    SIFH

*   An unbounded recursive loop could cause a crash.  The loop involved
    a dependent base class of the form X<D> where D is a dependent type
    and X is a template and is also the derived class.
    EBDT

*   We give a better diagnostic on misspelled versions of -esym, -efile,
    -etemplate, etc.
    MEOM

*   We were issuing an Error rather than just a Warning for a statement
    of the form:   "false;"
    TFIC

*   We were giving an undeserved Warning 1516 about a derived class
    member hiding a base class name;  A common idiom, however, is
    designed to do this exact thing such as:
            struct A { typedef T M; };
            struct B : A { typedef A::M M; };
    We now recognize this case and do not issue a 1516 when the
    derived class name is a typedef and has the same type as the
    base member type name.
    DCTM

*   ofstream operators when used for the first time with a type
    that triggers instantiation (of ofstream itself) could cause
    spurious bad type errors.
    MORS

*   We were not handling the following example of a template template
    parameter, a dependent template name and a partially specialized
    class template.
        struct C { template<class T> struct B { }; };
        template<template<class> class F, class T>  struct A; // #1
        template<class T >  struct A< T::template B, T > {};  // #2
        A< C::B, C > a;          // spurious error 1080
    HDTN

*   C99 allows the use of _Bool as a bit field as in:
        struct A { _Bool b : 3; };
    Under certain circumstances the use of that bit field had caused
    an infinite loop.
    SFB2

*   We gave an undeserved 571 (Suspicious Conversion) for the following
    example where us is unsigned short.
        u = (unsigned) (-(int) ( (unsigned) us ) );  // 571
    UOSC

*   There was a bug in the macro expansion that failed under certain
    circumstances to protect a macro from expanding twice.  The
    situation always involved the concatenation operator.  For example:
        #define G(a,b) a ## b
        #define D(x) G(x,C)
        #define A A.B
        D(A)
    would yield A.B.BC rather than the expected A.BC
    PPMN

*   We did not support explicit specializations for operator conversion
    templates.  E.g.
        class { template< class T > operator T (); };
        template<> A::operator char() { ... }
    OTNM

*   We were issuing an undeserved Info 759 (declaration can be moved
    from header to module) for a namespace symbol.
    FPND

*   We now detect 'short long' (accepted by some compilers) and issue
    a distinct error message (109) which can be suppressed by the
    user.
    SFSL

*   We were not printing line number information for all messages.
    In particular we were not printing out line number information
    when there was no file.  This could mess up front end's.
    DLNI

*   The compiler option -cgnu introduced a wrinkle (starting in 8.00o)
    in the lookup procedure for names of the form std::xxx, in order to
    conform with gcc's use of std. The wrinkle is now obsolete (applying
    only to GCC 2.95.x) and is now only available as an option (+fsg).
    GSGW

*   Within .vcproj files, we were automatically converting all commas
    within an include path to semi-colons.  However some users were
    using commas in their directory names (why not?).  This would
    result in errors.  We now do not convert commas, if they are found
    within quotes.
    PCED



*************** Version 8.00u 1/4/2006 ***************

*   An internal error (298) was being issued when using the obscure
    :> operator.  E.g.
      //lint -compiler(base_op)
      void foo( int a, int *b )
          { int j = a:>b; }
    would produce the unjustified 298.
    UTBP

*   We were issuing an undeserved 714 for functions that were
    declared with __declspec(dllexport).
    CDDR

*   A function declared/defined with the non-standard keywords:
    _interrupt, __interrupt, or __declspec(dllexport) no longer
    have the messages 714 (not referenced) or 765 (could be made
    static) issued on their behalf.
    SNUI and CDDR

*   static function templates, e.g.:
      template <class T> static void f( T );
    when instantiated could draw unjustified messages 528 (not referenced)
    and 401 (not previously declared static).
    QFST

*   Messages that were part of a Specific Walk that arose at function
    wrap up time (such as 429, Custodial pointer has not been freed)
    did not have an associated line number.