From owner-sc22wg14@open-std.org Mon Sep 7 03:20:06 2009 Return-Path: X-Original-To: sc22wg14-domo2 Delivered-To: sc22wg14-domo2@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 35A4DC178E2; Mon, 7 Sep 2009 03:20:06 +0200 (CET DST) X-Original-To: sc22wg14@open-std.org Delivered-To: sc22wg14@open-std.org Received: from outbound.MSE7.exchange.ms (outbound.mse7.exchange.ms [69.25.50.185]) by www2.open-std.org (Postfix) with ESMTP id 37C5BC178D9 for ; Mon, 7 Sep 2009 03:20:04 +0200 (CET DST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: (SC22WG14.11812) RE: Expected outcome + who is the customer? Date: Sun, 6 Sep 2009 21:20:01 -0400 Message-ID: <7CE7F921A61FC24F9C443A0E164BB3880628F1B2@ms12.MSE7.exchange.ms> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: (SC22WG14.11812) RE: Expected outcome + who is the customer? Thread-Index: AcomuNrlKZT/N2C4Qzq6fJhIva7WsAAz4J9QAfQfIyA= From: "Thomas Plum" To: Cc: Sender: owner-sc22wg14@open-std.org Precedence: bulk >> The "customer" covers the same marketplace as the audience for the >> C1x standard in general: compiler writers, tool vendors, lead >> programmers, programmers in general. > >Sadly static analysis tools have very little market penetration and >as my point 2 below notes the average developer does not know much >about the C Standard. This leaves compiler writers and we know that >most of these do pay attention to what the C Standard says. Whether the current marketplace for source analysis tools is "little", or "big", or whatever, is not directly relevant to the analyzer annex. The vendors of source analysis tools are directly and materially affected by the WG14 standards, so these issues are appropriate for consideration by WG14. There's a large group of people that should be mentioned here; I called them "lead programmers", but they include consultants, policy and procedures experts, methodology advisors, project leaders, etc. One important result of the analyzer annex comes when these experts determine which optimization options are permitted for the production (or "release") version of a company's application. If the project=20 organization is using source analysis tools (or human code review),=20 it becomes especially important that the machine code (as executed)=20 corresponds to the source code. =20 Further, the scope of analysis tools extends beyond any current marketplace for static analysis. Our convener made us aware=20 recently of a project called Deadbolt which uses source analysis to create specially-crafted testcases. And in an informal session after the Berlin meeting, Dave Keaton and I sketched an idea for Analyzer Advice, by which a backend compiler can make direct use of advice produced by static analysis. Here is a simplified example, using a source file named f.c: int f(int a, int b) { return a + b; } Analyzer Advice could report: File: f.c, line 2, token 3 signed integer add, needs overflow check At CERT, a specially-modified gcc has been used to test various ideas about integer-overflow checking; see description of the As-if Infinitely Ranged (AIR) integer model at http://www.sei.cmu.edu/library/abstracts/reports/09tn023.cfm If the runtime check fails, a runtime-constraint handler is invoked. Even in this prototype (produced by some very bright CS students), when every integer arithmetic op is overflow-checked, the added overhead is only a few percentage points (ranging from 2% to 6%, depending). When Analyzer Advice is incorporated into the backend=20 compiler, the static analysis frontend can determine specifically which ops need overflow-checking (depending upon policy choices determined by the operative guidelines). One obvious case of integer ops that need no checking are those in which the operands are seen at compile-time to be too small to cause overflow. Moving these determinations to the frontend compiler (which might even be doing some form of whole-program analysis) can simplify the job of the backend compiler; and if the Analyzer Advice is both machine-readable and human-readable, it can be code-reviewed as necessary for QA purposes. Tying this example back to the purpose of the analyzer annex,=20 if some of the integer ops are left to execute without any runtime checking, the analyzer annex still requires that those integer ops do not destroy the correspondence between the source program and the machine code as executed; i.e., the un-checked integer ops must produce some indeterminate result and not a "wobbly" result. Some may see this as too "technical" to be worth bothering with, but IMHO it is exactly what WG14 ought to be addressing in this revision of C1x. --------------------------------------------------------------------+ Thomas Plum, Plum Hall Inc, 3 Waihona Box 44610, Kamuela HI 96743 USA=20 tplum@plumhall.com .......... TEL +1-808-882-1255 FAX +1-808-882-1556 http://www.PlumHall.com ..... TOLLFREE +1-800-PLUM-HALL (800-758-6425)