bugfix80.txt

PC_LINT8_w,经过测试

*   We were not precomputing the value of enumerator comparisons.  For
    example we did not know that the if condition below was always true
    enum { false, true };  ... if( false == false ) ...
    SAEI, 4/20/05

*   For a typedef of a tagless struct (or enum or union) e.g.
      typedef struct { int a; } A;
    the typedef name is now considered a kind of tag that will
    identify the type uniquely even in the absence of other information
    such as found in the same code location.
    IETD, 5/2/05

*   In some contexts we failed to distinguish between a dependent type
    and a template partial specialization with the same template-id name
    resulting in undeserved Error messages.  E.g.
      template< class T, class U = int > struct B { typedef B<T> BT; };
      template< class T > struct B<T>;    // spurious Error 36
    This necessitated a fundamental change in our representation of
    a dependent type like B<T>.
    STSR, 5/18/05

*   We erroneously regarded static data members of a template as being
    defined when they are explicitly specialized.  E.g.
      template< class T > struct A { static int i; };
      template<> int A<double>::i;       // not a definition
    SDDI, 5/18/05

*   #including a header file whose name has trailing whitespace, e.g.
      #include "alpha.h "
    would result in an attempt to open precisely that name which would
    have the effect on some operating systems/libraries (Windows/MS)
    of opening the name without the trailing whitespace "alpha.h".  This
    could give obscure messages owing to the fact that we think the files
    are different but they're really the same.  We now remove trailing
    whitespace for the Wintel architecture.
    SWIF, 5/19/05

*   We were not always supporting array initializers with
    empty parentheses in constructors.
    AIIC, 5/23/05

*   Our value tracking now takes into account the size of arrays even
    though we are not actually tracking the value contained therein.
    E.g.
      struct A { int a[10]; };
      void f( A *p ) { p->a[10] = 0; }
    will register a complaint.

*   We were getting a crash within a tagless enum while parsing a
    template-id of dependent type (Boost library).
    CITE, 5/25/05

*   When within a template a template id would match a partial template
    specialization an inadvertent context change could occur that
    lead us to think that we were not in a template definition.
    TOKA, 5/25/05

*   The gcc variable-argument-macro convention allows for a null
    list to absorb a comma prior to any ## that precedes a
    name representing the list.  E.g.
      #define A(fmt,a...) printf(fmt,##a)
      ... A("hello world\n")
    now works as expected.
    GVMN, 5/24/05

*   When a base class within a template is a dependent type but it
    can be considered to represent a set of symbols we previously
    would search that set during unqualified name lookup.  This we
    no longer do (by default) owing to a recent change in the standard
    (2003).  It is necessary to obtain the old behavior for compiler
    libraries.  For this purpose ++template(40) can be used.
    ++template(40) is automatically switched on when we see the
    compiler code options: -cmsc and -cbc.
    FLBD, 5/31/05

*   For overloaded binary operators (like cout << n) the operator
    must be looked up both as a member function and as a global.
    When looked up as a member function we now follow the standard and
    employ qualified name lookup rather than unqualified name lookup.
    The latter cannot find names in base classes that result from
    dependent types.
    MSLC, 6/1/05

*   A call to a member template using both the dot operator and
    explicit template arguments could result in a crash.
    ETAC, 6/2/05

*   We further refined our notion of what it means to be a formerly
    dependent base class.  We were relying on the use of template
    parameters to indicate this but as the following example shows
    this is not conclusive.
      template<class T = int, class U = T > struct A { typedef int G; };
      struct B : public A<>
          {
          int f(G); // OK, G should be found in A<>
          };
    ILIB, 6/2/05

*   In processing template functions certain dependent expressions
    were assumed to have type 'int' rather than some unknown dependent
    type and as a result spurious messages would be given owing to
    a suspected conflict of types.
    CDDE, 6/3/05

*   When a static data member of a template is initialized (out of line)
    we did not always recognize when a nested name specifier
    nominated the current instantiation which led to undeserved errors.
    E.g.:
      template<class T>
          struct  A { typedef typename T::M M; static const M n; };
      template<class T>
          const typename A<T>::M A<T>::n = (A<T>::M)(-1);
    ICID, 6/3/05

*   In an explicit specialization the original template parameters
    are not supposed to be visible.  By default they no longer are.
    We require a special template bit (400) to make them visible as
    some compilers recognize the parameters in this context.  E.g.
      template< class T > struct  A { T n; };  // OK
      template< > struct  A<int> { T n; };     // T should not be in scope
    An option of ++template(400) would make the above behave as expected.
    With the compiler option -cmsc, the 400 template bit is set automatically.
    ESLP, 6/6/05

*   Our name lookup of an elaborated (unqualified) type (eg struct A)
    failed to take into account nominated namespaces.  Thus
      using namespace NS;
      struct A *p;
    did not always pick up a struct A that might be declared within NS.
    UNET, 6/7/05

*   The dependent base classes of a template should not be considered
    as formerly dependent base classes of an explicit specialization
    since the latter contains no dependencies.
    EFDB, 6/6/05

*   Corrected a problem involving Boost headers.  We locked up
    when attempting name lookup inside a base class with a dependent
    type of the form A<T>::M where T is a template parameter (such
    lookups are technically non-standard but some compilers support this).
    CLDB, 6/7/05

*   Running the Boost time headers through multiple passes resulted
    in a crash.
    OILC, 6/14/05
    DBKI, 6/15/05

*   In determining whether one function template is more specialized
    than another we were inadvertently triggering an instantiation
    of one of the template arguments.
    DUCI, 6/16/05

*   When a stringize operator (#) was used in a macro and
    the argument to be stringized contains two or more escaped quotes
    we did not escape the second escape.  Thus
      #define S(s) #s
      S( "\"quoted\"" )
    resulted in "\"\\\"quoted\\"\""
    rather than the expected "\"\\\"quoted\\\"\""
    NEBS, 6/20/05

*   With some partial template specializations the parsing of
    the template-id representing the partial template name
    having an argument which itself is a template-id could
    lead to obscure errors.  This occurs in Gnu's STL.
    TIWI, 6/21/05

*   Under conditions of deferred instantiation we did not reconsider
    the set of template partial specializations that might match the
    actual template argument list.  This occurs in the Rogue Wave
    interator headers.
    PPPF, 6/27/05

*   Under situations of extreme duress (owing to a lack of a lack
    of a critical namespace) it was possible to enter into an
    infinite recursion.
    IRIC, 6/28/05

*************** Version 8.00q 11/10/2004 ***************

*   A gratuitous new-line appeared in message 309 (#error encountered).
    The new-line was the character terminating the #error line.
    It is now removed.

*   We may have given an undeserved 1749 (base class need not be virtual)
    at global wrap-up when two or more modules process the same class
    definitions.

*   We now support the Exclude_From_Build feature of .dsp files.

*   We were not issuing a 1962 (contains a deep modification) when a
    function not declared as const indirectly modifies its class.  E.g.
       struct X { int *p; void f() { *p = 0; } };
    now issues a 1962

*   We were stumbling over Microsoft [in] [out] attributes in function
    prototypes (with the -cmsc compiler specified).  E.g.
       class S { void f( [in] x ); };

*   In the declaration:
       template< typename A::B(*pf)() > void g();
    we were interpreting the template parameter as a template type
    parameter and getting confused.

*   A tagless struct defined within a typedef is now considered to be
    a different type than any other tagless struct defined in some
    different location.  Thus after the declarations:
       typedef struct { int n; } A, B;
       typedef struct { int n; } C;
    A and B are considered to be the same type both different from C.
    One of the motivations for making the change was that the lob
    processing would consider A and C different whereas processing
    the original source files considered them the same.
    This change only affects typedef definitions.  The declarations:
       struct { int n; } a;
       struct { int n; } b;
    still regards a and b to be the same type even if declared in different
    modules.

*   A recursive template in the boost library (rational.hpp) was
    sending our template parser into infinite recursion.

*   There were some examples of function templates containing ellipsis
    that we were not handling properly.  We would not find a match.

*   The type of a suffixed constant of high precision (greater than
    a long) was in rare cases not properly determined.

*   When constants were larger than the precision that could be
    handled internally we would issue the confusing diagnostic
    "Error 30 Expecting a constant".  This has been upgraded to
    show the reason we did not like a constant.

*   The value-tracking analysis could regard a variable constant
    (such as const int n = 0;) as not necessarily equal to its
    original value as in:
       k = 3; if( n == k ) { ...
    shook our confidence that n was still 0.

*   We now print the location of the left curly when it is unmatched
    by a right curly.

*   We now support early modifiers in situations other than at
    global scope.  E.g.
       void f() { huge int *p; ... }

*   We now support .net attributes within prototypes.  Thus
    void f( [in] int k );
    now produces no syntax error.  Our support for attributes can
    be turned off using the -fat option (do not support bracketed
    attributes).

*   We now support extremely long -i options within .vcproj files
    by decomposing the -i option at ';' separators and forming
    separate lint options.

*   We were generating an undeserved 762 (redundantly declared symbol)
    in the following C code
       //lint +fmd          allow multiple definitions
       extern int i;        // declare i
       int i;               // define i  -->  Info 762
    This info 762 will now be supressed.  Subsequent tentative definitions
    in the same module will still draw the Info 762

*   When the maximum negative integer (0x80000000)was cast to long long
    and involved in multiplication there was danger of a stack overflow
    owing to unbounded recursion.

*   The internal type used to compute values for the purpose of
    value-tracking has been increased internally to 64 bits for
    PC-lint.  The number of bits for FlexeLint is determined by a
    pair of compile-type typedef's MAX_INT_t and MAX_UINT_t in
    custom.h.  By default these are long's.

*   Assigning a negative integer to an unsigned long long variable,
    or assigning large unsigned integers to a long long variable,
    if the computation precision is only 32 bits, could have resulted in the
    value tracking system getting wrong values for these variables.

*   We were issuing an erroneous report (message 793) of 'too many identifiers
    in one block' when what we really had was an unusually large
    number of -esym options.  The count of identifiers was not
    accurately reported either.

*   We were issuing an undeserved 952 (variable could be declared const)
    in the case of an enum using the integer model for enumeration (fie)

*   We were issuing an undeserved warning about a strong type violation
    within a template function that was specialized with a strong type.

*   We were insisting on a typename when in context a typename would
    be implied.  E.g.
       template<class T> class A;
       template<class T> A<T>::x f();

*   We were not able to pass a function template to an overloaded
    operator.  E.g.
       class X { public: X operator<<(X (*)(X));
			 X operator<<(bool); };
       template<class V> X g( V);
       X ac;
       void f() { ac << g; }
    This is a model in some libraries for manipulators such as endl.

*   We were not always successful in passing an overloaded function
    to an overloaded operator.  E.g.
       class X{};
       int operator+(int,X);
       int operator+(int (*)(int),X);
       double g(double);
       int g(int);
       int h() { X x; return g+x; }

*   During some look-ahead operations (for C++ overload resolution)
    temporary error suppression via -save -e... ... -restore
    was not having an effect.  This generally would occur when the
    save-restore sequence occured within the parentheses of the
    function call.

*   We were too aggressive in extracting information from templates
    specified via template-id with dependent argument lists.
    In many cases these should be regarded as dependent types and
    not element of some template.
    E.g.
       template <typename T> struct B { typedef T type; };
       template <typename T, typename U> class Test {};