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
          主站蜘蛛池模板: 日土县| 玉山县| 扶余县| 安阳县| 阿拉善左旗| 濮阳市| 河西区| 大庆市| 郧西县| 水富县| 礼泉县| 阿拉善盟| 绥化市| 龙岩市| 禹城市| 昌乐县| 湛江市| 会昌县| 湖北省| 垣曲县| 永昌县| 科技| 新化县| 天台县| 宝坻区| 阿合奇县| 通山县| 固安县| 灵宝市| 保亭| 镇平县| 淳化县| 文水县| 四川省| 特克斯县| 克拉玛依市| 赣榆县| 连江县| 黎川县| 华安县| 当阳市|