bugfix80.txt

PC_LINT8_w,经过测试

    MLN

*   A function's name is available only after the prototype is scanned.
    Thus the following is legal:
      typedef int A;
      void A(A);
    We did not recognize the legality of the construct.
    NHAD

*   We previously issued an undeserved 1053 (cannot distinguish between
    declarations) when a function declaration followed a function
    template with exactly the same function prototype.  E.g.
      template< class T > void f( int, double );
      void f( int, double );      // complaint
    DFTF

*   The use of the xml option which produces error messages
    in an XML format (through the use of the file env-xml.lnt)
    was marred by the fact that if a catastrophic error occurred
    the output file was not closed off with the proper </tag>.
    ACXE

*   Repeated Specific Walks of the same function during the same pass
    could give undeservd warnings because of an unanticipated value
    retention between walks.
    SLGZ

*   The MISRA 2 warning against the use of octal constants in
    escape sequences is now not issued in the case of octal 0.
    Thus '\0' is not deserving of a warning.
    AZOE

*   When a function template returns a specialization of
    a member class template we previously looked within the global
    space for a name of the class template which produced a confusing
    diagnostic.  E.g.
      struct A { template< class T > struct C{}; };
      template< class T > A::C<T> f(void);
      A::C<int> x = f<int>();
    MFNC

*   A strange crash, difficult to describe and more difficult to
    reproduce, was traced to retaining a pointer to a data
    structure that was growing.   The entire system was examined
    for similar malretentions.
    SDTC

*   We were issuing an undeserved Error 1024 (no function has same
    argument count) for the following example:
      template< class T, int u > struct A {};
      template< class T > int f( A<T,0> );
      A<int,0> a
      int i = f(a);
    The problem stems from comparing a function template call
    argument of type A<int,0> with call parameter A<T,0>.  The problem
    was not matching the T with the int, that's old stuff, but
    comparing 0 with 0 really threw us, we didn't realize they were
    the same.
    PEMC

*   In the example:
    ...
      template<class T> int B<T>::i = A<T>::f(2,3);
    during the external definition and initialization of static
    member i, we made the mistake of interpreting the comma
    in "2,3" as an operator rather than a function argument separator
    owing to a lack of symbolic information concerning the
    dependent A<T>::f.
    SFFD

*   Inconsistent results were obtained for ellipsis in the function
    parameter list of a function template:
      template< class T > int f( T, ... );
      int i = f( 1, 2 );
     NSGI

*   In MS .vcproj files we were not supporting a case-insensitive
    style of specifying tool names.  In particular 'VCCCompilerTool'
    can also be rendered as 'VCCcompilerTool'
    CIXP

*   In the one line suppression of the form:
        unsigned u = -1;      //lint !e570 loss of sign is OK
    the blank after 'lint' is necessary.  But the following worked
    halfway.
        unsigned v = -1;      //lint!e570   Bad
    It suppressed 570 but never unsuppressed it.  This has now
    been fixed so that the first half doesn't work either.
    RWLC

*   We were not reporting as an error the taking of the address of a
    non-static data member in a context where there is no implied this.
    ANSM

*   In an expression
      P op Q    // op is an operator
    If P is non-class type but Q is class-type we incorrectly search
    the scope of Q's class for member operators.  This was a regression
    from 8.00s to 8.00t.
    ACOO2

*   Circumstances could lead us to deduce that a variable typed
    unsigned something was less than zero.
    UDNZ

*   A member function within a local class could cause a crash by
    referencing auto variables in the outer function.
    FFRC

*   We no longer regard as uninitialized a member of a struct
    whose type has no constructor but is mentioned in an initializer
    list of a constructor with empty parentheses.  Instead this
    is considered to be zero initialized.
    EPZI

*   The output of parsing MS .net *.vcproj files contain -i options.
    In the past we would quote these options if blanks appear within
    the argument to -i.  Some users had blank-containing environment
    variables specified within the -i option and these caused problems.
    Now all -i options produced from *.vcproj files contain quotes.
    EIOX

*   Message 511 (size incompatibility) was enhanced to display the
    relative magnitudes of the source and destination.
    INMI

*   If a class with nested classes was defined (identically) in
    different modules (not at the same header location but at
    physically different positions in source files) and if a member
    of a nested class was accessed and if this were a C++ program
    we would issue an unjustified Error 115 (struct/union not defined).
    MPID

*   With Misra(2) enabled we were issuing an undeserved 16.3 violation
    for exception specifications.
    NIES

*   We were issuing undeserved Error 64 (type mismatch) while processing
    the definition of a class template and upon encountering an
    expression of the form:
      sizeof( f( g() ) )
    within a constant initializer.  The error was attributed to an
    overzealous attempt at overload resolution for g().
    QFAE

*   If a class with nested classes was defined (identically) in
    different modules (not at the same header location but at
    physically different positions in source files) and if a member
    of a nested class was accessed and if this were a C program
    we would issue an unjustified Error 115 (struct/union not defined).
    RNTS

*   We were issuing undeserved Error 64 (type mismatch) while processing
    the definition of a class template and upon encountering an
    expression of the form: sizeof( f( (PF) 0 ) )
    within a constant initializer where PF is a dependent type.
    TCTD

*   We did not report on anomolies of variables defined within for,
    while, if and switch clauses at block wrap-up time.
    CRCD

*   We did not support definitions of variables within switch clauses.
    ADSC

*   We now warn when the Microsoft Visual Studio version is 6 or
    earlier and there is an attept to initialize without parentheses
    a member (in a member initializer list) that has no constructor.
    LIMS

*   The location recorded for a macro had previously been the location
    of the last physical source line of its definition.  It is now the
    first line.
    LFPL

*   We now support syntactically MSC 8.0's __type_trait predicates.
    TTTP

*   Support was added for MSC 8.0's __identifier(id) option.
    SMIK

*   An option of the form -dname(param)=replacement was being
    reported as a 750 (macro not referenced).  Other macros
    introduced with -d do not get such a report.  This was
    disturbing in as much as the -d option was issued within
    a .lnt file that the programmer had not written.
    DOCM

*   When we complain (Error 30) that we expected an integer constant
    we sometimes would place a trailing '%s' on the message.
    EHSP


*************** Version 8.00t 10/10/2005 ***************

*   Some compilers allow offsetof() to be regarded as a constant
    permitting, for example, the declaration:
        int a[ offsetof(X,member) ];
    This is now allowed.  Also we now allow int casts of pointer casts
    of constants to serve as constants.  E.g.
        int b[ (int)(char *)10 ];
    CBPE

*   We were not issuing messages 729 (not explicitly initialized) and
    552 (not accessed) for static data members even though such
    messages were being issued for other data with static storage
    duration.  These messages are now issued for static members.
    USDM

*   Within base class specifiers, we presume a type even in the absence
    of typename. This is fine unless it's a template argument as in:
      template<class T> struct B : public D< (A<T>::m) > {};
    Here A<T>::m should not be presumed to be a type although by
    context it is safe to assume that D< ... > is a type.
    Similar modifications were made in the case of ctor initializers
    and in typedef contexts.
    DIBG

*   static member function templates when defined out of class were
    given a type consistent with their being non-static members.
    NDMT

*   Prior to an unqualified name lookup for an overloaded operator
    function, we did not request complete types for all operands
    which resulted in our not finding friend functions declared
    only within would-be instantiated templates.
        template< class T > struct A
            { friend bool operator !=( const A &, const A & ); }
        void f( const A<int>& a )
            {
            if( a != a )   // can't find friend operator
            ...
            }
    OLRC

*   We should have been but were not suppressing message 534 for a
    templated operator=.
    IRTA

*   A tagless struct within a macro within a C program could produce
    extraneous tokens.
    TSWM (follow on to IETD)

*   We now append a dialect denotation (C or C++) for each module
    in a module verbosity message.
    ADMV

*   We were issuing an undeserved message about an un-C-like structure
    when within a C++ module, a function, within an extern "C" scope
    contained distinctly C++ components.  The extern "C" is now
    regarded as pertaining to the interface and not the implementation
    of the function.
    TIDC

*   Owing to a recent change, we were not allowing the construct B::N
    in the example below.
      template< class T > struct A { typedef int N; };
      template< class T > struct B : A<T> { B::N m; }
    This would occur if the nested name specifier (B) is the current
    instantiation and the name (N) is not found and the current
    instantiation (B) has a dependent base class.  By the rules
    of qualified name lookup, the formerly dependent base classes
    are examined for names during template instantiation giving this
    qualified name another chance for success.
    QMRB

*   When a header contained a tag-less struct which contained a doubly
    nested substructure, e.g.
      typedef struct
          { struct A { struct B {} b; } a; } X;
    we would issue an unjustified Error 18 that X was redeclared
    when a 2nd module included the header.
    TSDN

*   There was a problem with identical structs being defined in (at least
    two) modules (not in headers).  This is bad practice in any case.
    During class wrap-up there was in some circumstances a noticable
    delay in processing.
    IDCH

*   We failed to give a message when a pointer to auto is transferred
    to an array in an outer block.
    APTA

*   We were issuing undeserved Error messages when classes were
    able to participate in expressions with built-in operators when
    the types expected by the operators were lvalues (e.g. increment,
    decrement) and the classes did provide conversion functions returning
    references to integral.
    ACOO

*   The message that typedef's are inconsistent has now been given
    Warning status with a separate message (452) as it strictly
    speaking is not an Error.
    CTNE

*   We were previously looking only inside the global namespace for
    the name 'type_info' which was valid at some time in the past
    but is no longer standard.  We now look in namespace 'std'
    (by the current standard) for this classname.
    If not found, we then search the global namespace.  A search for
    'type_info' implicitly occurs wherever typeid is used.
    HCST

*   Wherever typeid(arg) is used a complete type is required for the
    argument whether it is a typename or an expression.  We previously
    were not requiring a complete type and we were not reporting
    that a complete type did not exist.
    CACD

*   We were losing the predeclaration of namespace std in the 2nd
    and subsequent modules
    RSBS

*   A recent 'fix' introduced an irregularity in the value-tracking
    of nul-terminated strings embedded within arrays.  Our earlier fix
    protected our knowledge of arrays lengths across function calls
    (and after they have been assigned to pointers to non-const).
    But this protection went too far and retained our knowledge of the
    content as well.
    PFAI

*   A friend function explicitly declared to be at global scope
    could find its way into the nearest namespace.  E.g.
      void f();
      namespace N
          { class A { friend void ::f(); }; }
    now properly treats the global f() as a friend.
    FFDG

*   A member template function with an explicit template