read80.txt

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

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

    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 .NET ------

    As of patch level 8.00f we support Microsoft .NET.  There is a new
    compiler options file (co-msc70.lnt) for Visual C 7.0 and a new
    environment file (env-vc7.lnt) for Visual Studio 7.0.  A few new
    keywords have been added (__if_exists and __if_not_exists) and we
    can translate Visual C++ project files (with a .vcproj extension) to
    .lnt project files.  That is, when a file with a .vcproj extension
    is given to PC-lint, the .lnt project file will appear on standard
    out.  This is done in a manner similar to .dsp files (see section
    3.6 of the manual).  See also env-vc7.lnt to see how a tool can be
    created to automate the process.

    If a .vcproj file contains multiple configurations then PC-lint will
    accept the first configuration found unless the -dConfiguration=...
    option specifies a configuration other than the first.

    Patch level 8.00g fixed a few glitches.  The __if_exists 'statement'
    is not really a statement since it appears in a number of different
    contexts and so that had to be rewritten at the token level.  The
    .vcproj files had a little wrinkle.  We previously looked for
    "Source Files" but this categorization could not be relied on so now
    we just look for files with any of our C++ extents (extents can be
    added by the user via the +cpp option) or a .c extent.


               ------ 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.


                 ------ 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.

    See Section 9.2.2, "Interfunction Value Tracking".



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

    The following options have been added.

    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 propogating 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