From owner-sc22wg5@open-std.org  Wed Jan 28 22:44:06 2009
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom7
Delivered-To: sc22wg5-dom7@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id 60D26C178D9; Wed, 28 Jan 2009 22:44:06 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106])
	by www2.open-std.org (Postfix) with ESMTP id 6F558C178D6
	for <sc22wg5@open-std.org>; Wed, 28 Jan 2009 22:44:03 +0100 (CET)
Received: from mprox2.jpl.nasa.gov (mprox2.jpl.nasa.gov [137.78.160.141])
	by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0SLi1GL024585
	for <sc22wg5@open-std.org>; Wed, 28 Jan 2009 21:44:01 GMT
Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57])
	(authenticated bits=0)
	by mprox2.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0SLhwPs030863
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <sc22wg5@open-std.org>; Wed, 28 Jan 2009 13:43:59 -0800
Subject: Two requirements for critical software at JPL
From: Van Snyder <Van.Snyder@jpl.nasa.gov>
Reply-To: Van.Snyder@jpl.nasa.gov
To: sc22wg5 <sc22wg5@open-std.org>
Content-Type: text/plain
Organization: Yes
Date: Wed, 28 Jan 2009 13:43:58 -0800
Message-Id: <1233179038.15119.1117.camel@math.jpl.nasa.gov>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.3) 
Content-Transfer-Encoding: 7bit
X-Source-IP: math.jpl.nasa.gov [137.79.7.57]
X-Source-Sender: Van.Snyder@jpl.nasa.gov
X-AUTH: Authorized
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

I have just gotten a document frou the JPL Laboratory for Reliable
Software, specifying coding requirements and recommendations to increase
the reliability of critical software in C.  Most of these are to work
around defects in C, but two (which are requirements, not
recommendations) are germane to Fortran development:

1.  Declare data objects at smallest possible level of scope.

We've added the BLOCK construct.  The facility it provides to
encapsulate declarations in a region smaller than a scoping unit would
more likely be used if a specification part were allowed in every
<block>, not just a BLOCK construct.

2.  Use static and dynamic assertions as sanity checks.

These were on the J3 list in 2005, but didn't make it to WG5.

One of the justifications for this requirement was a study reported in
http://research.microsoft.com/apps/pubs/default.aspx?id=70290
("Assessing the relationship between software assertions and code
quality").  The abstract remarks "... with an increase in the assertion
density in a file there is a statistically significant decrease in fault
density. Further, the usage of software assertions in these components
found a large percentage of the faults in the bug database."