From owner-sc22wg5@open-std.org Thu Jan 29 00:57:44 2009 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id A4250C178D9; Thu, 29 Jan 2009 00:57:44 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mail1.cray.com (mail1.cray.com [136.162.0.111]) by www2.open-std.org (Postfix) with ESMTP id C3335C178D6 for ; Thu, 29 Jan 2009 00:57:42 +0100 (CET) Received: from beaver.us.cray.com (beaver.us.cray.com [172.30.74.51]) by mail1.cray.com (8.13.6/8.13.3/gw-5323) with ESMTP id n0SNvb4g022485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Jan 2009 17:57:37 -0600 (CST) Received: from CFEXFE01.us.cray.com (cfexfe01.us.cray.com [172.30.74.93]) by beaver.us.cray.com (8.13.8/8.13.3/hub-5273) with ESMTP id n0SNvXqv008537; Wed, 28 Jan 2009 17:57:33 -0600 Received: from mh-dhcp-172-31-16-180.us.cray.com ([172.31.16.180]) by CFEXFE01.us.cray.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 17:57:33 -0600 Message-ID: <4980F1A3.5020906@cray.com> Date: Wed, 28 Jan 2009 18:00:35 -0600 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Van.Snyder@jpl.nasa.gov, fortran standards email list for J3 Cc: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.3930) Two requirements for critical software at JPL References: <20090128214406.86E15C178D6@www2.open-std.org> In-Reply-To: <20090128214406.86E15C178D6@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jan 2009 23:57:33.0803 (UTC) FILETIME=[30145BB0:01C981A4] X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk Van Snyder wrote: > 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 > , 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." > > But then the "Lessons Learned" conclusion to the paper remarks "We believe enforcing the use of assertions would not work well." We have recently added features to Fortran that we now have to document with comments along the lines of "this feature is supported by the compiler because it is in the language spec, but we strongly recommend that it not be used in actual codes" because of disastrous performance implications. I hesitate to add more such features. I would note that our compiler (as a C program itself) contains an enormous number of asserts. They help in pinpointing bugs closer to the point where something went wrong (as opposed to much farther down the execution sequence when the consequences of the bug manifest as a fatal error). As such they are useful. We also get complaints that the compiler is slow. For a compiler that's not horribly serious. For production Fortran code poor performance is a non-starter. Different environments and different objectives. At a minimum, if we wanted asserts in Fortran, there would have to be a simple way to make them appear to be comments to the compiler. (Basically the old "D" lines.) Cheers, Bill -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120