bugfix80.txt

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

*   We now arbitrarily break template recursion and give a message
    indicating we are doing same.  The reason for this is that it
    is possible to define a recursive template as in:
	 template <class T> class A { A< A > x; };

*   We were not handling all uses of @ for the Cosmic compiler.
    In particular we were not handling @ as an introduction to a
    modifier.  For example:
	char * @near f();

*   We were issuing an unjustified 793 (external count exceeded ANSI
    limit) counting statics as externals

*   A complex initializer involving a template-id (i.e. an
    expression of the form: name< ... >) could trip up our
    look-ahead.  For example:
	 C x( NS::foo<int>() );
    was not parsed correctly because the look-ahead to break
    ambiguity involved a template-id.

*   Under some circumstances, when a member function of a template class
    was defined out of line we were not recognizing the function
    as a previously declared member.  The class had a non-type parameter
    and the function parameter was of the form C<I> and the out of line
    declaration used a slightly different form for the parameter than
    the inline.  E.g.
	 template< int I > class C { void f(C<I>); };
	 template< int I >  void C<I>::f(C)  {}
    This occurred in the MS header atlbase.h for VC7.

*   If two successive template parameters have the same name we would
    crash.  E.g.  template< class T, class T > void f();

*   When a template parameter contained a dependent type we could crash.
    E.g.
	 template< class T, T::M (*pf)() > ...
    Such a construct occurs in dxatlpb.h for VC7.

*   Our flag +fbu (bitfields are unsigned) was not being honored in the
    case of enumerations.  E.g. the following gave an unjustified constant
    out of range message.
	 //lint +fbu
	 enum E { a, b, c };
	 struct S { E m:2; } s;
	 void f() { if(s.m == c); }


*************** Version 8.00e 11/21/2001 ***************

*   Introduced Warning 686 suspicious option (unbalanced quotes)
    to cover what could be an almost undecipherable situation in
    processing lint options.  E.g.
	-i"C:\lint\"  std.lnt ...
    was parsed by the command processor to produce
	-iC:\lint"  std.lnt ...
    Warning 686 at least warns of the dangerous condition.

*   We now treat @ within a declaration specifier as being something
    that gets ignored with a Warning 431.  This enables compilers with
    syntax that resembles:
	@interrupt void f() { ... }
    to have a chance of working correctly.

*   We were issuing an undeserved 1928 (base class not on initializer
    list) when the base class had no constructor to begin with.

*   Added the ability to convert pragmas and/or preprocessor lines
    into macros.  This was needed by the ByteCraft compiler.

*   We were getting exceptions in template processing.  This would
    occur in template wrap-up activity when an instantiation of one
    function would trigger the instantiation of a template class.

*   When a base class within a template was originally a dependent
    type then it should not be searched for names during unqualified
    name lookup.  Since this is only a recent change in the standard
    and since most compilers do not support this change it is controllable
    via option: ++template(40)

*   We were issuing an unjustified Error 1050 (Expected a template
    argument list) while processing the Microsoft Standard Template
    Library.  We were finding the name "interator" in the base class
    iterator<int> which is not justified by the standard.  This was
    interfering with our finding class iterator.

*   We were issuing an unjustified 1549, 1550 and 1560 (exception thrown
    was not declared) within a function which had no exception
    specification and therefore is declared to throw any exception.

*   We were issuing an unjustified 1775 (catch block does not catch
    exception) when a function with no exception specification was called
    from within the corresponding try block.

*   A template function if the form:
    template< class T, class U > void f( const A<U> & );
    was not being matched by an argument of the form const A<type> &.

*   a user semantic option within a template could cause a crash.
    E.g.  template<class T> class A { /*lint -sem( a, custodial(1) )*/ };


*************** Version 8.00d 10/29/2001 ***************

*   We were issuing an undeserved 777 for the following:
    if( (x > 0) == (y > 0) ) ...
    where x and y are floating point numbers.

*   We now allow a variable number of arguments when a macro is
    defined using the -dname()=... form.  For example: -dasm()=0
    followed by:
	    n = asm( "mov a,3", "add b,a" );
    would work fine.

*   Allow unsigned integer constants for bit addressing.  E.g.
    a.0x3 = ...

*   We were issuing an undeserved 765 (could be made static)
    for a function whose only declaration is within another function.

*   rw_asgn(to,from) and ppw_asgn(to,from) did not work unless
    the from keyword was enabled.  For example to assign the meaning of
    "_to_brackets" to "IGNORE" you had to first enable the former as in:
	+rw(_to_brackets)  +rw_asgn(IGNORE,_to_brackets)
    This first option is no longer necessary

*   When the height of messages are 4 (-h...4) We were losing the
    first portion of the message (the format4a portion) when no
    location information was associated with the message.

*   __STDC_VERSION__ and __STDC_HOSTED__ are now pre-defined macros
    in conformance with the C-99

*   We were giving an undeserved 146 (binary constant) while processing
    assembly code.

*   -emacro({#,#},name) was not working.  Only the first # was supported.
    Our documentation did not give any example wherein this would work
    so its not strictly a bug but the presumed extension did not work.

*   Misra Rule 44 (redundant casting) is an advisory rule (961) but
    was issued as a required rule (960).  Our documentation on this
    was correct but the code was in error.  Rule 44 is now issued
    a Message 961.

*   An undeserved 1062 (template must be a class or function) was given
    for:
    template <class S, class T> void g(S (T::*f)() const) { }
    At some level we didn't think this was a valid prototype; the const
    was throwing us off.  This has now been fixed.

*   Support for the Cosmic C compiler's multi uses of @.  For example,
	volatile int n @ PORTADD + 2;
	@interrupt void f();
    required the introduction of the __at keyword.

*   Given a doubly scoped name (e.g., A::B::C) within a class X,
    if there was a B in class X we would pick up the wrong B.
    We now correctly confine our searching to A.

*   We were not supporting qualified name lookup for a namespace
    name properly.  We were giving ambiguous reference messages
    where none was deserved.  For example:
    namespace A { int a; } using namespace A; int a;  int n = ::a;
    would result in message 1075.  This would be a correct diagnosis
    if the global scope operator was omitted.  However when explicit
    namespace scoping is given (as in the above) then using directives
    are explored only as a last resort.

*   static items were not always visible when they should be.
    For example:
    namespace A { void f(); const int c = 3; }
    int A::f() { return c; }
    Here c is implied static and visible from within A::f but we
    claimed that it was undeclared in that context.

*   Templates were not being instantiated at the same library level
    in which they were declared.  This exposed too many template warnings
    on unsuspecting template users.  Template instantiation is now
    done at the same library level as the template definition.

*   We were reporting a 785 (too few initializers) with
    float x[10] = { 0 };
    when our documentation suggests that it would receive the more benign
    943.

*   We were not handling the situation where there were two independent
    definitions of a typedef'ed struct in two different modules.
    For example, if
    typedef struct A { ... } A_t;
    appeared in two different modules as independent declarations
    (i.e., not in the same header) we would properly give an origin
    error but then improperly assign the wrong type to A_t.

*   A template declaration of the form:
    typedef void (*F)( arglist );
    template < ... , F = function-name > ...
    i.e., where the parameter name was missing following a type (F in
    this example) would result in a misplaced diagnostic and possibly
    a crash.

*   We were giving an undeserved Error 40 within ole2.h for the
    identifier LPCLASSFACTORY when processing the second (and
    beyond) modules that were including COM header files.
    The problem was triggered by an unusually complex interaction
    between ole2.h and unknwn.h in which each was including the other
    making use of the #pragma once to break the recursion.  It turns
    out we neglected to reset our internal once flags.

*   We were issuing an unjustified 798 (redundant character) for the
    following sequence:
    #if 0
    #define A
	\
	x
    #endif
    The message was issued only in cases that conditional compilation
    indicated should NOT be examined.


*************** Version 8.00c 8/16/2001 ***************

*   A delete of a complex expression such as
	delete member[i];
    where the type is a pointer to a class that has a destructor
    could cause the issuance of internal error 257
    plus an infinite loop.

*   An undeserved MISRA Violation (message 960) is issued
    for a simple delete.

*   There was an undeserved 929 (cast from pointer to pointer)
    for any delete.

*   We were issuing Internal Error 212 with Gnu C.  The problem
    would occur when a new was encountered after size_t was
    (re)declared as unsigned long.


*************** Version 8.00b 8/8/2001 ***************

*   For messages 525 (negative indentation), 725 (expected positive
    indentation, and 539 (did not expect positive indentation),
    we were issuing a "location unknown" as part of the 830 message.

*   When the fai flag was turned off with a -fai (it is normally ON)
    we were not only regarding an argument whose address was passed
    to a functions as being possibly uninitialized as the documentation
    says but we were making a similar deduction with regard to
    the "this" argument when non-const member funtions were called.
    This was neither justified by the documentation nor by common
    sense and so "this" arguments are now immune to this treatment.

*   A false 960 message (Rule 69) was issued for a C++ catch clause
    using an ellipsis.

*   An undeserved 960 message (MISRA rule 68) was issued for
    any class or namespace function defined in file scope level.

*   We were issuing an undeserved 306 (previously encountered module)
    when processing a lob file in a multi-pass setting.

*   Message 641 (converting enum to int) has been parameterized with the
    name of the enumeration.

*   Message 910 was issued when we were assigning 0 to something other
    than a pointer.


*************** Version 8.00a 7/26/2001 ***************

*   If there is a side effect on the right hand side of a logical
    operator and if operator op() is defined or declared then
    an inexplicable Bad Type (61) and Type Mismatch (64) could
    occur.

*   We were giving an undeserved 133 (too many initializers) for the
    following code which is actually deemed legal by the C++ standard.
    struct A {} a = {};

*   In converting .dsp files to .lnt files we would not previously
    process SOURCE lines bearing module names that are quoted.

*   If a module name contained a blank then the second and subsequent
    passes (if any) would split the name at the blank.

*   An undeserved Error 2 (Unclosed Quote) could occur with two adjacent
    string constants following a template class expression that
    gets instantiated.