*************** Version 9.00e  -- July 20, 2010 ***************

*   A pre-compiled header could result in a crash when using semantics of
    the form -sem(A::name,...) where A is defined within a pre-compiled
    header.
    PHSI, 12/7/09

*   Strings that were previously limited in size are now unbounded
    in length.  The option ++macros no longer has any effect.
    IVLS, 12/8/09

*   Some compilers that target embedded systems provide a C/C++ core
    language extension that enables the user to specify, in a declaration
    of a statically-allocated variable or a function, an address where the
    declared entity is to be stored.  Example:
            int a @ 0xFF02;      // 'a' is at memory location 0xff02
            int b @ 0xFF00 = 42; // initializes b, at 0xff00, to 42
    In our parser's support for this in variable declarations, we were
    treating the address specifier as a component of an initializer, which
    meant that we would parse it only within the context of a definition
    and not in a forward-declaration.  Example:
            extern int c @ 0xFF04; // forward-declaration of c; Lint 9.00c
                                   // trips here.
    But the compilers that support this feature all regard the specifier
    as separate from the initializer and allow it in forward-declarations.
    So the grammar for /init-declarator/ is:
        init-declarator:
                declarator  [address-specifier]   [initializer]
        address-specifier:
                '@'     constant-expression
    This is now reflected in our parser.
    ASIC, 12/08/09

*   There was a problem with our representation of a using-declaration
    that refers to an enumeration constant.  Symptoms arose only during
    LOB and PCH absorption.  E.g. the following
        namespace N { enum E { a = -1 }; }
        using N::a;
    elicited a "corrupt LOB" message.
    CLEU, 12/09/09

*   During argument dependent lookup (ADL) [basic.lookup.argdep], we were
    not searching in the namespaces associated with template arguments of a
    specialization that is an associated class (as we should have).  With
    a version of GCC's STL implementation, this led to undeserved errors
    with uses of find() with arguments of type vector<T>::iterator defined
    as:
        typedef __gnu_cxx::__normal_iterator<T*, std::vector<T> >
                iterator;
    During ADL, Lint would search for 'find' in __gnu_cxx but not in std.
    Now we also take template arguments into account, so std is searched
    as well in this case.
    Furthermore, we were not considering namespaces associated with
    argument types composed of function types.  Example:
        namespace N {
            struct A { };
            void f(void (*)());
        }
        void g();       // #1
        void g(N::A);   // #2
        void h() {
            f(g); // ok.
            // The type of #2 causes ADL to search for 'f' in N,
            // and then overload resolution selects #1 as the
            // argument.  Versions 9.00d and earlier issued Error 1055 for
            // this example.
        }
    ALPB, 12/09/09

*   During PCH creation, we were outputting symbols of namespace-scope
    entities that had not been declared in the current translation unit.
    SE1P, 12/09/09

*   In a using-declaration in a class template with a dependent base
    class, we would assume more than we really knew about the set of base
    classes; example:
        struct A { void f(); };
        template<class T> struct B : public A {};
        template<class T> struct C : B<T> {
            using A::f; // 9.00c7 gives undeserved Error 1091 here
            // 1091: 'struct A' is not a base class of 'template C<<1>>'
        };
    AUBD, 12/09/09

*   If a function template was used in the initializer of a static data
    member of a class template, it could trigger an undesired
    instantiation of a specialization of a function template whose
    template arguments depend on a template parameter.  Example:
        template<class T> T& f( T& t )
            { return t; }// Undeserved Error 36 here
                         // during instantiation (at module wrap-up time)
        template<class T> struct A;
        template<class T> struct B {
            static A< T > j;
            static int i;
        };
        template <class T> int B<T>::i = f(B<T>::j);
    ICUI, 12/09/09

*   We now support emulation of Microsoft's "nested #include search"
    feature, in which an include-directive of the form:
        #include "a.h"
    causes the search for 'a.h' to consider first the directory of the
    including file and then the directories of all other
    actively-including files (from most nested all the way through the
    directory containing the primary source file) before considering
    directories specified by '-i' options.
    DOIF, 12/09/09

*   When the definition of an instantiated class X was required for the
    first time in the definition of another instantiated class Y, we would
    fail to recognize X as "defined" when the definition of Y was required
    for the first time in a translation unit but not for the first time in
    the lint run.  Example:
        // t.h:
        template<class T> struct A { int m; };
        template<class T> struct B { A<T> v; };
        static const
        B<int> c={{42}};  // Undeserved Error 121 here (during t2.cpp).
        // 121: Attempting to initialize an object of undefined type
        //     'struct A<int>'
        // t1.cpp:
        #include "t.h"
        // t2.cpp:
        #include "t.h"
    ICU2, 12/09/09

*   When a non-type template parameter declaration appeared soon after a
    use of a parenthesized initializer, a parse failure would result.
    int n(42);
    template<char *(*p)()> // Error 10 here
        class A {};
    DTPD, 1/5/10

*   We issued a flow-through message within a switch in spite of the
    fact that the user had placed an option that indicates that the
    code is unreachable.
    NAUO, 1/9/10

*   An undeserved 794 "Conceivable use of null pointer" could occur
    for a variable that is guaranteed non-null before a loop and
    is not modifified (but tested) during a loop) and is used after
    the loop.
    UCUN, 1/24/10

*   When FlexeLint was compiled for 64-bit systems, there were an awkwardly
    high number of diagnostic messages.  These have been fixed.
    SSFB, 1/27/10

*   In a member access expression, if the id-expression began with the
    :: scope resolution operator, we would issue a spurious Error 10.
    Example:
        struct  A { void g(); };
        struct  B : public A { void g(); };
        void f( B c ) {
            c.
                :: // Spurious Error 10 ("expecting identifier") here
                A::g();
        }
    GSRN-EP-100127-1
    MABI, 1/27/10

*   When a strong dimensional type (Jd or just J with +fdd) is divided
    by itself the result was not what was expected.  The result was
    the type itself.  It is now resolved properly with the result
    being a dimensionally neutral type.
    DSDT, 1/28/10

*   Corrected a crash which resulted from what lint thought was a
    function within a function within a function (for C code which
    can use K&R style function definitions this is much more likely
    to happen)
    FWFC, 2/1/10

*   Under certain obscure circumstances we issued an undeserved 1413
    when a reference to const pointer was being bound to a pointer.
    E.g.
        typedef void* const & R;
        void * & q();
        R m(  )
          {
          return q(); // Undeserved Warning 1413 here
          }
    FWRR, 2/2/10

*   It was possible for a function parameter to be less capable than
    the corresponding argument, considered ok by the language, and
    allowed by our normal argument passing algorithm but rejected by
    our overload resolution mechanism.  E.g. the following issued an
    undeserved Error 1025.
        void g( const void *const *  );
        void g( int );
        void f( void  *const *p)
            { g( p ); }
    ORCC, 2/2/10

*   When an undeclared identifier was used in a base-specifier in the
    definition of a class template at namespace scope, and when that class
    template was followed by a "generic" function template (as defined by
    MISRA C++), an Internal Error would be issued with subcode=2009.
    Example:
        namespace N {
            template<class T> class B : A<T> { };
            template<class T> void f(T); // IE subcode=2009 here
        }
    DSTI, 2/5/10

*   Note 975 ("Unrecognized pragma") would be issued about an unknown
    pragma even in a region of a source file that had been made inactive
    because of conditional compilation.
    // GSRN-PP-100121-2
    UPIN, 2/8/10

*   We would issue an undeserved Error 1051 for a function following a
    type-dependent using-declaration of the same name that followed a
    typedef.  Example:
        template <class  T>
        struct A : T {
            typedef T X;
            using T::f;
            int f(); // Undeserved Error 1051 here
            // 1051: Symbol 'f' is both a function and a variable
        };
    // Report ID: GSRN-DC-100125-1;
    TCDU, 2/8/10

*   We were accidentally lowering the probability of initialization
    for a function parameter when that parameter's address was passed
    to another function and the -fai flag was used.
    GSRN-IN-091222-2
    IUFA, 2/9/10

*   The notation
        :: operator delete( ... )
    would not always find the global (builtin) operator delete().
    GSRN-OV-100204-4
    NFGO, 2/11/10

*   We were complaining about a suspicious constant (message #620) in
    the case of an integer-suffix with a 'u' followed by an 'l' (ell),
    such as:
        long ell = 0xFFFFul;
    The message has been surpressed for this type of situation.
    LFUS, 2/11/10

*   We were issuing messages about violations of the MISRA 2 Rule 19.2
    (Header file name with non-standard character) for headers
    #include'd by use of -header() options.  This issuance was deemed
    to be a bit of needless noise and is now silenced.
    MMLH, 2/11/10

*   Silence the issuance of complaints of MISRA rule 4.1 violations,
    if the code appears in a "#if 0" region.
    NMUR, 2/11/10

*   We were reporting the modification of a member of a local
    structure object as possibly modifying non-local data when such
    non-locality was not possible.
    IIMA, 2/12/10

*   When -p and -summary were used (but without an output filename to
    -summary), the summary output would appear as part of the preprocessed
    source code (and not as part of the diagnostic output, which in -p
    mode goes to stderr or to a file specified by -oe(filename).)
    GSRN-PP-100203-3
    SIPO, 2/15/10

*   Update to au-misra2.lnt;  several rules labeled as "not currently
    supported" have been recognized as being supported or as "not
    statically checkable".
    RMRI, 2/18/10

*   We now report on the syntax error of duplicate type-specifiers
    such as:
        signed signed int i;
    For this change we have introduced a new message, #29: Duplicated
    type-specifier.
    DTOL, 2/22/10

*   When a variable with internal linkage and namespace scope appeared in
    a pre-compiled header, and when the primary source file used to
    generate the .lph was subsequently used in a Lint run for the
    absorption of the same .lph file, undeserved Errors could result.
    Example:
        t.h (PCH):
            namespace N { static int M; }
        t.cpp:
            #include "t.h"
            int S = N::M; // Undeserved Error 1075 here after PCH
                          // absorption
    SNTP, 2/23/10

*   We now report on violations of MISRA C 2004 rule #17.4 and MISRA
    C++ rule #5-0-15, relating to pointer arithmetic.
    MPPA, 2/23/10

*   We now report on violations of MISRA C 2004 rule #16.9 and MISRA
    C++ rule #8-4-4, relating to the use of function identifiers.
    FIBI, 2/24/10

*   We now report on violations of MISRA C 2004 rule #11.5 and MISRA
    C++ rule #5-2-5, relating to casting away const or volatile
    qualifications.
    CACV, 2/24/10

*   When a primary source file's name was given to Lint with a leading
    './', and when that file contained one direct #include of a header
    file and one indirect #include for the same header file named with
    '../', we could erroneously see the two #includes as referring to two
    different header files; this would lead us to incorrectly evaluate
    '#pragma once' and undeserved errors could ensue.  (This was not seen
    on POSIX, where Lint uses device and serial numbers indicated by
    stat() to determine file identity instead of normalized path names.)
    Example:
        Directory structure:
            s/x
            s/x/a.lnt
            s/x/b.h
            s/x/t.cpp
            s/y
            s/y/a.h
        s/x/a.lnt:
            +pragma(once,once)
            +fdi
            ./t.cpp
        s/x/t.cpp:
            #include "b.h"
            #include "../y/a.h"
        s/x/b.h:
            #pragma once
            #include "../y/a.h"
        s/y/a.h:
            #pragma once
            struct X {  int x; };  // Undeserved Error 39 (redefinition)
        Invocation:
            lint-nt.exe -i"s" a.lnt
    DCFN, 2/25/10

*   We now report on violations of MISRA C 2004 rule #8.7 and MISRA
    C 1998 rule #22, reporting when objects with static storage are
    accessed by only one function and, therefore, can be moved to block
    scope.
    SFAS, 3/15/10

*   The letter 'i' (or 'I') when used as an integral suffix received
    no warning.
    WPIS, 3/16/10

*   We now report on violations of MISRA C 2004 rule #12.13 and MISRA
    C++ rule #5-2-10 relating to increment and decrement operators.
    IDOO, 3/17/10

*   We now report on violations of MISRA C 2004 rules #6.1 and #6.2
    and MISRA C++ rules #5-0-11 and #5-0-12 relating to the type of char.
    PCCO, 3/17/10

*   We were waiting too long to instantiate a template and giving a
    false error #1058 when attempting to initialize a reference to a
    base class with a dereference pointer of a derived
    instantiated-template class.
    CYNE, 3/19/10

*   class names are normally represented in diagnostic messages by
    simply their name and without a class key.  That is class X would be
    represented as 'X' and not by 'class X'.  However, if the class
    is defined with the keyword 'struct' and if it is a POD (Plain Old
    Data) object it is represented with the class key 'struct'.  Thus
    "struct A { int a, b; }"  is represented as "struct A" and not "A".
    This is a slight change from earlier when the criterion was
    aggregate rather than POD.  The reason for the change was to make the
    POD property more apparent as only these can be arguments to functions
    such as memcpy().
    CPSN, 3/22/10

*   We adjusted our calculation of the MISRA underlying type for
    character literals based on new information from MISRA.
    CMUT, 4/5/10

*   We now warn about the use of %a or %A when in C90 mode or in C++
    (prior to 2010) mode.
    PAFC, 4/6/10

*   We enhanced our support for detecting violations of MISRA C 2004
    rule #6.1, MISRA C++ rule #4-5-3, and MISRA C++ rule #5-0-11 to
    include relational and arithmetic operation violations.
    MPCO, 4/7/10

*   We now detect violations of MISRA 1998 rule #27, MISRA 2004 rule
    #8.8 and MISRA C++ rule #3-2-3 relating to the declaration of
    external objects.
    EDOF, 4/7/10

*   We were not allowing an rvalue to be thrown to a reference to non-const.
    As the standard says, the rvalue is used to initialize an
    exception object which is permitted to be passed to a reference
    to non-const.
    CPNR, 4/9/10

*   In a declaration that names a function template specialization,
    access-checking would be applied to the declarator-id, and an
    undeserved diagnostic would result.  Example:
        class  A { template<int I> void f(); };
        template<int I> void A::f() {}
        template<> void A::f<1>() {} // Undeserved Error 1060 here.
    ACDN, 4/9/10

*   The initializer of a static data member of a class template could
    elicit an undeserved type-mismatch error.  Example:
        struct A{};
        template <class T> struct X { static A n; };
        template <typename T> A X<T>::n =
            T::f(); // Undeserved Error 64 here
    ITSD, 4/9/10

*   We corrected an issue involving non-working -elibmacro() options
    for systems which use a '.' character as an alternative wildcard.
    UWCP, 4/16/10

*   We were issuing an undeserved MISRA C++ Rule 11-0-1 violation
    by reporting on non-private data members that were static and
    also typedef's and enum's.  The rule should only apply to non-static
    data members.
    TDNP, 4/22/10

*   Our emulation of Microsoft's treatment of __if_exists was not
    sufficient to treat Boost.Typeof as the Microsoft compiler does.  In
    particular, we would always regard a template specialization as
    "existing", since a specialization otherwise springs into existence
    when it is named for the first time.  But not so in the context of the
    condition of __if_exists.  Example:
        //lint -cmsc -w1 +e1501
        template<class T>struct X{};
        struct Y { __if_exists(X<int>){void q;/*MSVC: ok*/} };
        typedef X<int> A;
        struct Z { __if_exists(X<int>){void q;/*MSVC: error*/} };
    GSRN-TM-100301-1
    IETS, 4/27/10

*   We now detect violations of MISRA 1998 rule #115, MISRA 2004 rule
    #20.2, and MISRA C++ rule 17-0-2 relating to the reuse of standard
    library macros and objects.
    RRRM, 5/3/10

*   We enhanced support for Borland's __property extension so as to
    prevent complaints about missing 'this' objects within the body of
    the __property declaration.
    AOPB, 5/4/10

*   For a case where a class template was used before its first
    declaration, and then declared, and then used again, as in:
        template<class T> A<T> b;
        template<class> class A;
        typedef A<char> C;
     we issued:
        Error 200: Internal Error, subcode=2033
    ... which is Lint's way of claiming that Lint has a bug, and the claim
    arose because when Lint tried to determine whether the specialization
    would be instantiated, it found that its own internal data about the
    template was ill-formed.  But that's really because the code is
    ill-formed, so we should have a Recovery Error instead of an Internal
    Error.
    GSRN-TM-100428-1
    RTLT, 5/6/10

*   We now highlight violations of MISRA 1998 rule #36, MISRA 2004
    rule #12.6, MISRA C++ rule 4-5-1, and MISRA C++ rule 5-3-1 relating
    to the use of Boolean expressions.
    SUBE, 5/7/10

*   We now detect violations of MISRA C 1998 rule #34, MISRA C 2004,
    rule #12.5, and MISRA C++ rule #5-2-1 relating to the operands of
    logical operators.
    PLOO, 5/7/10

*   -indirect( xxx.lnt ) could cause a crash if used within a lint
    comment within a template.
    IOWT, 5/13/10

*   (Version 1X) Introduced support for parsing a trailing-return-type.
    NFDS, 5/14/10

*   We now report on violations of MISRA C 1998 rule #74, MISRA C
    2004 rule #16.4, and MISRA C++ rule #8-4-2 relating to identical
    identifiers in the declaration and definition of a function.
    IIDD, 05/18/10

*   We now detect violations of MISRA C 2004 requirement #10.6, and
    MISRA C++ requirement #2-13-3 relating to the use of the 'U' suffix.
    SUUC, 05/18/10

*   We now report on violations of MISRA C 1998 rule #16, MISRA C
    2004 rule #12.12, and MISRA C++ rule #3-9-3 with regards to
    accessing the underlying bit representation of floating point
    values.
    FPBU, 05/21/10

*   Header files found by searching the directory of the including file
    (using, of course, quotes as opposed to angle brackets on
    the #include line) often had their names displayed using the
    full file name (complete path name) even though the +ffn flag
    was not set on. Display of such header file names is now in accord
    with the display of names found using a directory specified with
    a -i directive.
    SFNA, 6/2/10

*   In the following example the explicit constructor for B(int)
    was not ignored in the following ocde:
        struct B { explicit B(int); };
        struct A
            {
            A( int, ... );          // 1
            A( const B&, bool );    // 2
            };
        void f()
            { A( 1, 42 ); }
    This produced an ambiguous call message.
    ECNI, 6/2/10

*   A template-argument naming a C++/CLI pointer to garbage-collected
    storage, where the name of the pointee type is undeclared, would
    elicit an infinite loop.  Example:
        //lint -cmsc(clr)
        template<class T> void f();
        template<>        void f<A^>();
        //GSRN-HP-100602-1
    CPUC, 6/4/10

*   It was possible to produce output lines with unusually large widths
    in spite of the fact that there was a nominal bound on their width
    (-width(M)) as is the case by default.  This was because we would
    wait for a blank before breaking.  Some template id's could go
    on for thousands of characters before that happened, however.
    We now force a line break after exceeding M+60 characters, and
    sooner if a convenient line-end character has been found.
    IMOW, 6/8/10

*   By default, we now limit MISRA C messages to C modules and MISRA
    C++ messages to C++ modules.  This presumption, however, may be
    altered with the use of either or both of two new arguments to the
    -misra() option:
        CinC++: to activate MISRA C messages for C++ modules
        C++inC: to activate MISRA C++ messages for C modules
    EMAO, 06/15/10

*   We were inadvertently considering undefined macros mentioned in a
    bypassed or pre-compiled header as defined.
    AUML, 06/16/10

*   We now provide rudimentary support for the MS .vcxproj file.
    The usage follows along the line of the .vcproj file.
    VCXP, 6/17/10

*   Added the ability to process MS .sln files which produces a
    batch script consisting of a sequence of lint executions.
    PMSF, 6/23/10

*   (Version 1X) We were issuing an ambiguity message when overloaded
    functions differed only by R-value vs. ordinary reference. E.g.
        void g( const A & );
        void g(       A && );
        ...
        g( A() );       // undeserved 1023
    DRRL, 7/8/10

*   An undeserved 1023 (overload ambiguity) was being issued when
    using constructors to convert arguments by not taking into account
    a secondary standard conversion from the class to the parameter.
    ORIC, 7/9/10

*   In code compiled against MSVC, a use of __uuidof() (whether implicit,
    as in an implicit use of a default argument to a template parameter,
    or explicit) that appears in the /condition/ of if(), while(), for(),
    etc. could elicit an undeserved parse error message.
    UUTA, 7/9/10

*   In code compiled against MSVC, Lint would see __int32 as a synonym for
    'long'; we now see it as a synonym for 'int' (as Microsoft does in
    both 32-bit and 64-bit modes).
    WU32, 7/9/10

*   (Version 1X) A move constructor ( e.g., A( A&& ); ) was being
    flagged as a 2nd copy constructor.
    RTMC, 7/12/10


*************** Version 9.00d  -- December 7, 2009 ***************

*   (C++ Version 0X) Implemented support for explicitly defaulted
    special member functions.
    DAUF, 6/11/09

*   When attempting to declare a namespace/block scope function
    multiple times with default arguments, Lint would crash.
    DAPC, 6/15/09

*   We were not properly overloading function templates on return type
    alone.  (This behavior is necessary to support SFINAE tactics like
    those involving boost::enable_if.)
    TRTO, 6/17/09

*   (C++ Version 0X) implemented 'explicit' conversion functions as
    per document N2437
    IICO, 6/18/09

*   A recent modification revealed a slight logic error involving
    default arguments, resulting in an internal error.  We have
    corrected this error.
    DAIE, 6/18/09

*   (C++ Version 0X) augmented IICO to add support for explicit
    conversion functions to be implicitly used for contexts in which
    there is a contextual conversion to Bool
    RBCC, 6/23/09

*   We were not applying the -size() option to function parameters.
    SSAP, 6/23/09

*   Our declaration/expression ambiguity resolution in C++ mode was
    incorrectly recognizing some expressions as declarations.  Example:
       struct  A { A(int); A & operator<<( int ); };
       void f(int n) {
           A(n) << 42; // Lint 9.00c gives an undeserved Error 18 here.
       }
    ESAD, 6/23/09

*   Given:
        struct A{enum{e};};
    ... seen on a given line in a file t1.cpp and in a different location
    in t2.cpp (and not in a header file), and given a separate .LOB file
    generated from each of those sources, a crash would result when
    reading the LOBs.
    CDLA, 6/26/09

*   A while clause that resembles a declaration, but then contains
    a syntax error resulting in nothing plausible as an initializer,
    could result in a crash
    SECC, 8/4/09

*   We were not previously considering the cv qualification of
    implicitly invoked operator conversion functions.  This would
    have made it impossible to discriminate between:
        operator const int*() const;
        operator int *();
    WAFM, 8/16/09

*   The implicit conversion of operands for built-in functions was
    not being reckoned properly during the overload resolution phase.
    There was a tendency to regard sub-integers as not arithmetic.
    Thus the predicate:
        d != 0
    where d was of type D was receiving an undeserved ambiguity
    message when class D had operator conversion functions:
        operator A*();
        operator bool();
    This should select operator bool().
    AIBO, 8/28/09

*   During unqualified name lookup from within a member function of a
    nested class, there were circumstances in which we would fail to find
    members of an enclosing class.
    SSUM, 8/31/09

*   If a file was initially used as a header file and then as a source
    file, the -header() option failed to apply to it.  Example:
        // files t2.cpp, t3.cpp and a.hpp are all empty; t1.cpp contains
        // only:
        #include "t2.cpp"
        // Invocation:
        // lint "-header(a.hpp)" -w1 -vf t1.cpp t2.cpp t3.cpp
    In this case, a.hpp was not included at the top of the translation
    unit for t2.cpp.
    MHOI, 9/8/09

*   Within a .vcproj file, we were not converting "&quot;" into a
    double quote for a PreprocessorDefinitions string.
    QWVD, 9/9/09

*   We were confusing dimensionless arrays with zero-length arrays
    (disallowed by ISO C/ISO C++ but allowed by some compilers because of
    uses in legacy code, e.g. in the implementation of the FreeBSD system
    call interface, where zero-length arrays are used as part of an
    ancient hack to force alignments).  This led to undesired instances of
    Error 157.
    ZDMN, 9/10/09

*   We added the basic architecture needed to report the number of
    messages from each category given during the processing of each
    function.
    PFMC, 9/15/09

*   When relational operators are used as 2nd arguments to logical
    AND (&&) or logical OR (||) in the control clause of a while
    or for statement we could issue an undeserved 685 (Relational
    operator always evaluates to true).
    ROMO, 9/17/09

*   An internal error 200, though designed to include a subcode,
    was lacking same.
    IELS, 9/17/09

*   Suppose we have a strong type (call it X) whose underlying type is an
    ordinary class type (call it Q).  While doing strong type-checking for
    an assignment from X to Q, we did not recognize the relationship.
    Example:
        //lint -strong(AJX)
        struct A { void f() {} };
        typedef A X;
        void g( X t ) {
            t.f(); // undesired Warning 639 here (for the initialization
            // of the implicit object parameter of A::f()).
        }
    MAES, 9/17/09

*   (C++ Version 0X) The diagnostic about inconsistent deduced types for
    the 'auto' type-specifier was not being issued.
    DDTN, 9/18/09

*   An option of the form -dname=... could create difficulty if the
    ... contained an unbalanced left brace or left paren.  Thus
    -dLB={ did not work as expected as it was capable of gobbling up
    neighboring text (in a .lnt file).  A quoted form such as
    -d"LB={" would always work.
    RMDO, 9/30/09

*   We were issuing some undesired diagnostics involving
    __property members (a feature of the C++ Builder compiler).  The
    undesirability is a result of Lint's current interpretation of each
    __property member as an ordinary non-static data member.  That
    interpretation has not changed, but the number of undesired
    diagnostics about property members has been significantly reduced.
    Also, we were issuing undeserved diagnostics about 'read' and 'write'
    functions not being referenced.
    QBPS, 9/30/09

*   Our handling of overloaded operators -> did not take into account the
    possibility of a cycle; e.g.:
        struct B;
        struct A { struct B& operator->(); };
        struct B { struct A& operator->(); int n; };
        int  f( A & p ) { p->g(); } // 9.00c2 loops infinitely here
    This, coupled with a bug in the name lookup for overloaded operators
    '->', led to an infinite loop in:
        struct  X { void g(); };
        struct  B {
            X* operator -> () const;
        };
        struct  A {
            B m;
            B& operator -> ();
            void h() {
                m->g(); // 9.00c2 loops infinitely here
            }
        };
    Also, certain other class member operators were inappropriately found
    by name lookup during the search for non-member functions (specified
    in [over.match.oper] in ISO C++); this led to undeserved errors when
    those operators competed in overload resolution.  Example:
        struct B { B& operator/=(const double& r); };
        struct A {
            B   v;
            A& operator/= (const double& r) {
                v /= r; // Spurious 1023 here
                return *this;
            }
        };
    IUOA, 10/7/09

*   Changed error message for fpatch.c when unable to open for
    writing.
    FUOW, 10/9/09

*   In Microsoft emulation mode (for VC++6), the processing of an explicit
    specialization requires a special behavior where the names of the
    primary template's template parameters are placed in scope (as if each
    parameter was a typedef name for the corresponding template argument
    of the specialization).  But we were not prepared for an explicit
    specialization to appear inside a class template definition, and this
    case could cause a crash to occur later in processing.  Example:
        template<typename T> struct G {
            template <typename U> struct H {};
            template <>  // Ill-formed by ISO C++;
                         // Ok by all versions of MSVC++ to date.
                struct H<int> {};
        };
    NEEF, 10/29/09

*   When the value of a pre-increment or pre-decrement of a char is
    passed to a function, the overload treatment of the expression
    assumed the type to be an int.  The correct type is, of course,
    a char.
    TPID, 11/4/09

*   Our use of template function specializations as candidates
    for overloading needs to be restricted to those resulting from
    template matches of the current argument list.
    Explicit specializations and specializations resulting implicitly
    from prior argument lists need not and should not be considered.
    ICPC, 11/5/09

*   MAES introduced a regression:  an undeserved Error 138 would be
    issued on a typedef where the underlying type is a class type whose
    unqualified name had been used to declare a different type.  Example:
        struct A {};
        struct C { struct A : ::A {}; };
        typedef C::A B;  // Undeserved Error 138 here
    USLM, 11/12/09

*   USLM introduced a regression where a typedef of a name previously
    given in a -strong() option could result in a crash if the underlying
    type was a class that had not been declared before the typedef.
    Example:
        //lint -strong(AJX,V)
        typedef struct A V;
    ECMI, 11/16/09

*   When the argument to delete is a class we gave an undeserved 1043.
    The standard allows an object of class type to follow delete
    as long as it has a single non-explicit conversion function to a
    pointer to object type.
    ADIC, 11/18/09

*   Pre-compiled headers were not working properly with C++ using the
    co-msc80.lnt or co-msc90.lnt compiler options files.
    The problem involved the typeinfo header inclusion.
    PHMH, 11/30/09


*************** Version 9.00c  -- June 15, 2009 ***************

*   A function given the cleanup semantic as in:
         -sem( X::f, cleanup )
    when called by a non-destructor did not sufficiently clean up
    the value state of pointers to avoid issuing an undeserved
    Warning 423 (Creation of memory leak).
    GSRN-AL-081219-1
    CCFI, 12/22/08

*   (C++ Version 0X) Implemented Forward Declaration of enumerations
    FDOE, 12/30/08

*   We were issuing an Internal Error 1275 in Boost metaprogramming
    headers.
    UCTA, 1/5/09

*   We could crash with the option +fab enabled while parsing iostream
    that ships with Visual Studio 2008.
    Related: We have removed instances of +fab from Microsoft support
    files, since the extension it mimics does not appear to be supported
    by recent versions of the Visual C++ compiler; also, proper behavior
    now depends on its absence.
    RGAB, 1/5/09

*   The following construct resulted in undesired errors when seen
    in second and subsequent modules:
        typedef long M;
        struct X { M M; };
    This code is technically ill-formed but is seen in popular library code.
    CPMH, 1/5/09

*   Two -atomic(...) options in a .lnt file would result in a crash
    at the first module.
    AOIC, 2/18/09

*   When processing GCC headers without a proper configuration (i.e.
    without a macro definition for __attribute__ supplied in co-gcc.lnt),
    a crash could occur.
    GFTM, 2/19/08

*   (C++ Version 0X) Added support for R-value references.
    IRVR, 2/16/09

*   In the definition of a tagless class inside a user-defined namespace
    where a function template had previously been declared, an internal
    error could result.
    ARGT, 2/19/08

*   At the point where a conversion occurs in the passing of a non-type
    template argument to a non-type template parameter of type 'void*',
    Lint would issue Internal Error 1285.
    ZPNT, 2/19/08

*   We now support functors stemming from conversion functions that
    return pointers to functions (or the equivalent).  Previously we
    only supported "operator()" as the basis of a functor.
    PFAF, 3/10/09

*   We were not implementing a form of direct reference binding that
    involved use of a conversion function.  For example:
        struct A { operator int&(); operator const int&(); } a;
        int f( int& );
        int k = f( a );
    should select, from the pair of functions, the most appropriate one
    using overload resolution.  We were previously issuing 1037
    (ambiguous reference) for this case.
    DRBC, 3/31/09

*   An undeserved message (456) could be issued from within a member
    function in which a mutex lock (semantic 'thread_lock') was set
    but not released.
    BLMM, 4/1/09

*   (C++ Version 0X) Revised R-value references so as not to bind directly
    with lvalues.
    RRBL, 4/2/09

*   For the purpose of overload resolution we were placing a const
    qualifier on rvalue arguments to a function.  This practice was
    found to be no longer required and not particularly accurate
    for the purpose of type deduction (with function templates)
    and so has been discontinued.
    NNAT, 4/20/09

*   A crash could occur with ill-formed template code
    IFTC, 4/23/09

*   (C++ Version 0X) The new character types (char16_t and char32_t) have
    been implemented (N2249).
    INCT

*   (C++ Version 0X) Implemented the L-value reference deduction (for when
    a function parameter has the type T&&) and reference collapsing rules.
    DLVR, 4/22/09

*   (C++ Version 0X) Implemented underlying types for enums.
    IUTE, 4/22/09

*   (C++ Version 0X) Implemented initial support for deleted functions.
    Example:
            void f( char* );
            void f( void ) = delete;
            void g( char* s ) {
                f( s ); // ok
                f(); // Error: Use of deleted function 'f(void)'
            }
    N2346, DELF, 4/29/09

*   (C++ Version 0X) disembodied non-static data members are now allowed
    as arguments to sizeof (and friends).  (N2253)
    SNMT, 4/30/09

*   (C++ Version 0X) The decltype feature has been implemented.
    ATDK, 5/6/09

*   We were failing to disambiguate the following pair of conversion
    functions for an implicit conversion from B to some type T.
        struct B { operator T(); operator T() const; };
    In particular, we were issuing an undeserved report of an ambiguous
    reference to a conversion function when using the Boost library.
    CFSB, 5/15/09

*   (C++ Version 0X) the nullptr type (N2431) was added.
    NDAI, 5/21/09

*   When a friend declaration named a specialization and the template-id
    named more than one template argument, undeserved Errors could result.
    Example:
        template <class T,class U> struct A;
        template <class T,class U> bool f();
        template <class T,class U> struct A {
            friend bool f<T,U>(); // 9.00b3: Undeserved Error 151 here
        };
    (This was reduced from '#include <boost/unordered_map.hpp>'.)
    PASS, 05/01/09

*   Resolved an issue in our handling of an initializer in a
    /condition/ [see stmt.select in ISO C++]; e.g.:
        struct A { operator bool() const ; };
        void f() {
            if ( const A& b = A() ) /* OK */ {}
        }
    ...which in version 9.00b3 elicited the undeserved Errors 1072 and 111.
    HICO, 05/12/09

*   Added support for the 'alignof' keyword for C++0x.  A synonym for this
    keyword (spelled '__alignof') is now also enabled in Microsoft
    compatibility mode (i.e. when -cmsc is specified).  The '__alignof'
    variant spelling may be used to enable this keyword more generally, as
    in -rw_asgn(__alignof__,__alignof)
    ALGN, 05/15/09

*   Added support for the special macro __COUNTER__ (implemented in MSVC++
    version 13.00 and up, GCC 4.3 and up and possibly other compilers).
    The behavior is as specified in Microsoft's documentation:
        "[__COUNTER__] Expands to an integer starting with 0 and
        incrementing by 1 every time it is used in a compilation unit.
        __COUNTER__ remembers its state when using precompiled headers. If
        the last __COUNTER__ value was 4 after building a precompiled
        header (PCH), it will start with 5 on each PCH use."
    Our spelling of the macro is '__lint__COUNTER__'; so e.g. to enable
    '__COUNTER__' when linting code compiled against MSVC++, one can add:
        -d"__COUNTER__=__lint__COUNTER__"
    ...to one's Lint configuration.
    MSCN, 05/20/09

*   We corrected a slight incompleteness of +estring behavior as
    compared with the Lint documentation.  For example, options of the
    form +estring(958,member) would not actually activate message 958
    for a message parameterized with the word 'member'.  Other message
    numbers were being handled correctly.
    ESAM, 6/4/09

*   It was not possible to activate msg 970 (Use of modifier or type
    'Name' outside of a typedef) for a particular modifier or type.
    Now, for example, +esym(970,long) will behave properly.
    ENWF, 6/4/09

*   In Microsoft emulation mode (for VC++6), the processing of an explicit
    specialization requires a special behavior where the names of the
    primary template's template parameters are placed in scope.  There
    were two issues with our emulation:
        1) the underlying types of the injected typedef names were incorrect
        2) we were doing the emulation for all versions of the Microsoft
           compiler (but only VC++6 has this extension)
    Both issues are now corrected.
    CVGA, 06/09/09

*   An attempt to set the built-in length of size_t to long-long (via
    the pair of options +fzl ++fzl) resulted in undeserved 516 Warnings).
    AONC, 6/8/09

*   It was not possible to set a size (using -s...) after setting
    the +fzl (sizeof is long) flag.
    RPCN, 6/12/09


*************** Version 9.00b  -- December 18, 2008 ***************

*   We now issue the Misra message that indicates that there is a signed
    (named) bit field of length less than 2.

*   (C++0x) Added support for scoped enumerations.

*   If program_info() were used with multiple passes there would be
    a repeat of local variables.

*   An illegal access could occur when a Microsoft .vcproj file is
    processed by FlexeLint on a Unix-like platform

*   Compiling our shrouded (FlexeLint) code results in a warning
    about an implied conversion from char** to char const * const *.
    This harmless conversion is allowed in C++ but not in C.

*   Detection of Misra C++ rule violation (abstract class contains
    user-defined copy-assignment-operator with public access)
    for Elective Note 1960.

*   Detection of Misra C++ rule 15-1-2 violation (throw NULL)
    was added to Elective Note 1960.

*   Detection of Misra C++ rule 11-0-1 violation (non-private data
    members in non-POD types) was added to Elective Note 1960.

*   We were crashing when a too-large string was being read in from
    a pre-compiled header (.lph file).

*   Functions defined in libraries which by default are not processed
    (would need the +flf flag) were regarded as pure; this led to false
    positives (Warning 522).  They are now regarded as impure.

*   We were not complaining (Elective Note 1960 and Misra C++ required
    rule) that a void-returning function (g) has no side-effects when
    it only calls a template function (h) that has no side-effects.
    Example:
      template< class T > void h() {}
      void g() { h<int>(); }
    Here h<int> has no side effects and for that reason we should
    deduce that g has no side-effects which we failed to do.

*   We were issuing Info 1795 when in unit check (-u) mode.  This message
    is now suppressed for unit check.

*   When +source was combined with html output (such as using env-html.lnt)
    source characters involving < > and & were not properly escaped.

*   Using xml or html output modes we now transform quotes
    into an escaped version of the quote, i.e. &quot; when such quotes
    appear within variable portions of a message (such as %m in a
    -format option).

*   We were issuing an Elective Note 963 for generated members of a
    struct.  This was not desirable because the user has no control
    over the style of declaration chosen.

*   We were issuing (fatal) Error 328 when a -header option caused to
    have included a sub header of a pre-compiled header.  The same
    effect could be seen when instead of designating the header as
    pre-compiled it was designated as bypass.

*   The option -sem( operator=, ... ) was not treated properly.
    If fact if there was an '=' character in the name of the function
    difficulties ensued.

*   An explicit template instantiation saved in a pre-compiled header
    was not being restored properly and the restoration resulted
    in Internal Error 200, subcode 2032

*   Thread semantics were sometimes not picked up for static functions

*   Due to an issue with our internal formation of expression trees
    involving class member operator functions, some -sem() options would
    not take effect when applied to said functions.

*   Added the following semantic to lib-stl.lnt:
      -sem(std::auto_ptr::auto_ptr,custodial(1))
    which indicates that the auto_ptr constructor takes custody of the
    pointer.

*   The option --source was added; it can be used to turn off the
    echoing of source lines.

*   In the context of a template definition, a call to a function template
    using an explicit template argument of dependent type could result in
    infinite recursion.

*   In /clr mode the Microsoft Compiler (Vers 2005+) allows 'public'
    to precede a class or enum definition.  We now accept this keyword
    when -cmsc(clr) is given.

*   A problem with PCH headers would result in the set of overrides
    for a function being mangled.  This resulted in one case in an
    Error 328.

*   Functions defined within a PCH header were omitted from the set
    of functions considered for modifying static values.  This could
    result in Warning irregularities for static variables.

*   We were issuing a false message (Info 845 -- is certain to evaluate
    to 0) for an expression involving a class data member where said
    member was involved in either a || or an && expression.

*   Our method of forming class template specialization types differed
    slightly between template-id parsing and template argument
    substitution for a dependent specialization type; as a result in some
    cases we would issue Internal Error 1242 during template argument
    substitution in a call to a function template.

*   Although we previously warned of returning an auto variable via
    a reference return type, we did not catch the case of returning
    a reference to an auto variable which is equally aggregious.

*   In C++, in the declaration of a member of a tagless struct, a use of
    another member of the same tagless struct could yield Internal Error
    1229.

*   The bypass options were missing from the help information

*   A crash could occur when lob files were used in multiple passes

*   We were issuing an undeserved 587 (Predicate can be pre-determined)
    in some cases involving negation and unsigned variables.  e.g
    if( u - 1 == 0 ) ...   // undeserved 587

*   we were issuing a Warning 443 (for clause irregularity) when the
    loop variable initialization was buried in a larger expression as
    in:  for( k = i = 0; i < 100; i++ ) {}
    The consensus seemed to be that this was not sufficiently irregular
    to warrant the message.

*   We were issuing an unjustified internal error (1261) when either
    a Boolean was passed to one of the scanf family of functions or
    when a %c format was used in connection with the scanf family.
    GSRN-HP-081211-1

*   We were issuing an undeserved Warning (1416 -- an uninitialized
    reference is being used to initialize a reference)
    for the following:
      struct S { int const &m; S( S const &s ) : m( s.m ) {}  };

*   We were ignoring the inference-yielding properties of a predicate
    that was always true in the false branch of an if.  E.g.
      int n = 100;
      if( n > 50 ) return;
    we still "think" n is 100 which could lead to false conclusions.

*   When using bypass headers, a function call involving two (overloaded)
    function candidates from two different namespaces can result in the
    wrong function being selected.