jinfeng_wang

          G-G-S,D-D-U!

          BlogJava 首頁 新隨筆 聯系 聚合 管理
            400 Posts :: 0 Stories :: 296 Comments :: 0 Trackbacks

          http://www.splint.org/manual/html/sec1.html



          Splint[1] is a tool for statically checking C programs for security vulnerabilities and programming mistakes.  Splint does many of the traditional lint checks including unused declarations, type inconsistencies, use before definition, unreachable code, ignored return values, execution paths with no return, likely infinite loops, and fall through cases.  More powerful checks are made possible by additional information given in source code annotations.  Annotations are stylized comments that document assumptions about functions, variables, parameters and types.  In addition to the checks specifically enabled by annotations, many of the traditional lint checks are improved by exploiting this additional information.

           

          As more effort is put into annotating programs, better checking results. A representational effort-benefit curve for using Splint is shown in Figure 1.  Splint is designed to be flexible and allow programmers to select appropriate points on the effort-benefit curve for particular projects.  As different checks are turned on and more information is given in code annotations the number of bugs that can be detected increases dramatically.

           

          Problems detected by Splint include:

          ·      Dereferencing a possibly null pointer (Section 2);

          ·      Using possibly undefined storage or returning storage that is not properly defined (Section 3);

          ·      Type mismatches, with greater precision and flexibility than provided by C compilers (Section 4.1–4.2);

          ·      Violations of information hiding (Section 4.3);

          ·      Memory management errors including uses of dangling references and memory leaks  (Section 5);

          ·      Dangerous aliasing (Section 6);

          ·      Modifications and global variable uses that are inconsistent with specified interfaces (Section 7);

          ·      Problematic control flow such as likely infinite loops (Section 8.3.1), fall through cases or incomplete switches (Section 8.3.2), and suspicious statements (Section 8.4);

          ·      Buffer overflow vulnerabilities (Section 9);

          ·      Dangerous macro implementations or invocations (Section 11); and

          ·      Violations of customized naming conventions.  (Section 12).

           

           



          Figure 1.  Typical Effort-Benefit Curve

           

          Splint checking can be customized to select what classes of errors are reported using command line flags and stylized comments in the code.  In addition, users can define new annotations and associated checks to extend Splint’s checking or to enforce application specific properties (Section 10).

           

          About This Document

          This document is a guide to using Splint.  Section 1 explains how to run Splint, interpret messages and control checking.  Sections 2–13 describe particular checks done by Splint.  There are some minor dependencies between sections, but in general they can be read in any order.  Section 14 covers issues involving libraries and header file inclusion important for running Splint on large systems.

           

          This document does not describe technical details of the checking.  For technical background and analysis of Splint’s effectiveness in practice, see the papers available at http://www.splint.org

          posted on 2007-05-25 17:59 jinfeng_wang 閱讀(632) 評論(0)  編輯  收藏 所屬分類: cpp 、ZZ
          主站蜘蛛池模板: 宝山区| 汽车| 太湖县| 平度市| 宁波市| 岐山县| 永新县| 汶上县| 洛浦县| 平顺县| 平阳县| 汤阴县| 社旗县| 札达县| 武宣县| 淅川县| 新巴尔虎右旗| 昌吉市| 宜川县| 札达县| 汉川市| 金山区| 深水埗区| 炉霍县| 安平县| 冕宁县| 清河县| 万源市| 张北县| 安义县| 彭山县| 伊宁县| 道真| 巩义市| 敦煌市| 大宁县| 溧水县| 嘉善县| 大名县| 大化| 平武县|