read80.txt

PC_LINT8_w,经过测试

             --------------------------------------------------
                   --- Manual Additions/Modifications  ---
             --------------------------------------------------
                       PC-lint for C/C++ Version 8.00w

    This readme.txt supplements the on-line PC-lint manual entitled
    "Reference Manual for PC-lint/Flexelint" found in the installation
    directory under the name "pc-lint.pdf"

    You have permission to print out the reference manual in whole or in
    part only in support of the authorized use of this software and not
    for general distribution or resale.


               ------ Support for Microsoft Version 8  ------

    We currently support Microsoft Visual C/C++ 8.0 (as well as all
    earlier versions of the Microsoft compiler series).  Support comes
    mainly from the compiler options files (co-...lnt).  For example
    options files co-msc70.lnt, co-msc71.lnt and co-msc80.lnt support
    versions 7.0, 7.1 and 8.0 respectively.


              ------ Support for Borland Project Files  ------

    As of patch level 8.00j we support the Borland 6.0 Project Files
    (.bpr) in a manner similar to the support for Microsoft .dsp and
    .vcproj files.  That is the command:
    
          lint-nt  a.bpr
    
    will generate to standard out options and names of modules that it
    finds within the project file.  The default location of the Borland
    system is:
    
          c:\program files\borland\cbuilder6
    
    This can be modified by presetting macro BCB.  Thus
    
      lint-nt -d"BCB=c:\\my program files\\borland\\cbuilder6" a.bpr
    
    is the appropriate command if the location of CBuilder6 is in the
    directory specified.


                      ------ A caveat for 8.00p  ------

    When moving to Patch level 8.00p from the prior patch level (8.00o)
    you might experience a problem whereby a previously suppressed
    message is no longer suppressed.  This could occur with the use of
    -esym employed upon an identifier within a class within a namespace.
    For example:
    
          namespace A
              {
              class B { int n; };
              }
    
    will now correctly indicate that A::B::n is not used whereas earlier
    patch levels indicated that B::n was not used.  A use of an option
    of the form:
    
          -esym( xxx, B::n )
    
    will now be ineffective in suppressing the message.  The preferred
    option is to use the full name including namespace as in:
    
          -esym( xxx, A::B::n )
    
    If there are a large number of such options and if it would be an
    unbearable chore to make the above change for each and every one of
    those options then another possibility exists.  You may employ, for
    example, the following option:
    
          -esym( xxx, [*::]B::n )
    
    The brackets specify an optional sequence and is currently
    undocumented.  This suppresses message xxx for B::n and for every
    B::n embedded in any namespace or nested sequence of namespaces.
    This technique allows for a search and replace operation to alter a
    large number of esym options relatively painlessly.


                ------ Printing the Reference Manual  ------

    You have permission to print out the Reference Manual (or other
    related documentation) in whole or in part in support of the use of
    this software.


                          ------ What's New  ------

    To find out what we've added to the product since Version 7.50,
    check out Chapter 18 "What's New" in the Reference Manual.


                          ------ Front End  ------

    Your linting experience will be considerably enhanced by adapting
    your favorite editor or compiler environment to the task of
    sequencing from error to error.  See Section 3.5 of the Reference
    Manual.


                       ------ Multiple Passes  ------

    By default, PC-lint/FlexeLint will go through all your modules in
    one pass.  For projects not previously linted there will be enough
    messages to look at.  However, with just one pass, you will not be
    taking full advantage of our new interfunction value tracking.  With
    just one pass, we will not know about dangerous return values for
    functions that are defined later than they are called, and we will
    not know about dangerous arguments for functions that are defined
    early.  To introduce a second pass you need only to add the command
    line option:

        -passes(2)

    or, if this syntax presents a problem with your Shell, you may use:

        -passes[2]

    or, in some cases,

        -passes=2

    is needed.  Of course, you can replace the 2 with any number you
    wish.  The larger the number the more bugs can be found and the more
    time will be required.

    See Section 9.2.2, "Interfunction Value Tracking".



                      ------ Additional Options  ------

    The following options have been added.

    o  Commercial @ is a modifier (+f@m)
       This is a feature required by some embedded compilers that employ
       a syntax such as:
       
             int @interrupt f() { ... }
       
       The @interrupt serves as a modifier for the function f (to
       indicate that f is an interrupt handler).

       Normally '@' would not be allowed as a modifier.  If the option
       +f@m is given then '@' can be used in the same contexts as other
       modifiers.  There will be a warning message (430) but this can be
       suppressed with a -e430.  The '@' will otherwise be ignored.  The
       keyword that follows should be identified either as a macro with
       null value as in -dinterrupt= or as a reserved word using
       +rw(interrupt).

    o  Parse .net attributes, +fat
       Dot net (.net) attributes are contained within square brackets.
       E.g.
       
         [propget, id(1)] void f( [out] int *p );
       
       The square brackets and information contained therein is a non
       standard extension to the C/C++ standards supported by the
       Microsoft Visual C 7.00 compiler.  Remarkably this doesn't appear
       to interfere (or be ambiguous) with other uses of square brackets
       within the language.  For this reason the flag is normally ON.
       To turn off such processing use -fat.

    o  Explicit Throw flag (+fet)
       In early releases of 8.0 (8.0d and earlier) we provided a method
       of checking exception specifications to prevent exception leaks,
       etc.  Unfortunately we were too aggressive and a number of
       programmers pointed out that since a function that doesn't
       declare to throw can throw any exception, then it is at least
       theoretically possible that by adding an exception specification
       to a function that doesn't have one, you will induce the dreaded
       unexpected() call.

       So we made the appropriate modifications and we began getting the
       opposite complaint.  Some programmers were quite happy with the
       old system since it allowed them to track and control their own
       exceptions especially in situations where library functions with
       undocumented exceptions were non-existent.

       To resolve the problem and make everyone happy, version 8.00g has
       a new flag.  The Explicit Throw flag (+fet) is normally OFF.  If
       the flag is OFF then the absence of an exception specification
       (the throw list for a function) is treated as a declaration that
       the function can throw any exception.  This is standard C++.  If
       the flag is ON, however, the function is assumed to throw no
       exception.  In effect, the flag says that any exception thrown
       must be explicitly declared.  Consider
       
             double sqrt( double x ) throw( overflow );
             double abs( double x );
             double f( double x )
                 {
                 return sqrt( abs(x) );
                 }
       
       In this example, sqrt() has an exception specification that
       indicates that it throws only one exception (overflow) and no
       others.  The functions abs() and f(), on the other hand, have no
       exception specification, and are, therefore, assumed to
       potentially throw all exceptions.  With the Explicit Throw flag
       OFF you will receive no warning.  With the flag ON (with a +fet),
       you will receive Warning 1550 that exception overflow is not on
       the throw list of function f().

       The advantage of turning this flag ON is that the programmer can
       obtain better control of his exception specifications and can
       keep them from propagating too far up the call stack.  This style
       of analysis is very similar to that employed quite successfully
       by Java.

       The disadvantage, however, is that by adding an exception
       specification you are saying that the function throws no
       exception other than those listed.  If a library function throws
       an undeclared exception (such as abs() above) you will get the
       dreaded unexpected() function call.  See Scott Meyers "More
       Effective C++", Item 14.

       Can you have the best of both worlds?  Through the magic of
       macros it would appear that you can.  Define
       
             #define Throws(X) throw X
       
       which then is used as:
       
             float f( float x ) Throws((overflow,underflow))
                 { ...
       
       Notice the required double set of parentheses which are needed to
       get an arbitrary list of exceptions into a single macro.

       When you compile you can define Throws to be null and when you
       lint you can define Throws as above.  This can be done most
       easily by doing a #ifdef on the _lint preprocessor variable
       (defined while running our product).

    o  Function takes Custody flag (ffc)
       This flag is normally ON.  It signifies that a function will
       automatically assume custody of a pointer if the argument is not
       of the form const T * where T is some type and is not library.
       Turning this flag OFF (with a -ffc) will mean that a given
       function will not take custody of a pointer unless explicitly
       directed to do so via a custodial semantic for that function and
       argument.  See option -sem.  See also message 429.

    o  The Inhibit Inference flag (fii)
       This flag is normally OFF.  It had been by default ON in versions
       of PC-lint/FlexeLint prior to versions 8.00m.  The purpose is to
       suppress inference formation during Specific Walks and during the
       evaluation of expressions involving nul-terminated strings.
       These inferences were prone to error and were resulting in
       undeserved messages.

       Owing to steady progress in the accuracy of making such
       inferences the flag has been made default OFF.  To obtain the
       prior behavior (i.e.  as it was in version 8.00L) turn the flag
       on with +fii.

    o  Macro Concatenation Flag (+fmc)
       If the flag is ON, a token immediately following a macro with
       parentheses, will, in effect, be pasted on to the end of the last
       token of the macro replacement.  For example, the code
       
             #define A() a
             int A()x;
       
       will normally be greeted with an error according the ANSI/ISO