From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Jan 16 20:11:14 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 43125356C84; Wed, 16 Jan 2013 20:11:14 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) by www.open-std.org (Postfix) with ESMTP id 9B4A53569F3 for ; Wed, 16 Jan 2013 20:11:11 +0100 (CET) Received: from CFWEX01.americas.cray.com ([136.162.34.11]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKUPbfhl5CHfufedkivz2XZo8fJYsrbW72@postini.com; Wed, 16 Jan 2013 09:12:40 PST Received: from fortran.us.cray.com (172.31.19.200) by CFWEX01.americas.cray.com (172.30.88.25) with Microsoft SMTP Server id 14.2.318.1; Wed, 16 Jan 2013 11:07:14 -0600 Message-ID: <50F6DE46.8050601@cray.com> Date: Wed, 16 Jan 2013 11:07:18 -0600 From: Bill Long Reply-To: Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.4898) [ukfortran] Comment on a comment on the WG5 letterballot on N1947 References: <20130108205438.50F4E356B56@www.open-std.org> <20130113210632.B1C67356BEA@www.open-std.org> <20130116050422.92E30356BE0@www.open-std.org> In-Reply-To: <20130116050422.92E30356BE0@www.open-std.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk On 1/15/13 9:05 PM, Malcolm Cohen wrote: > Bill Long wrote: >> >> Page 42, Fortran.58.1, bullet 1: Unless you go to absurd lengths, >> detecting integer overflow is only practical if there is hardware >> support for this capability. > > This is mistaken. > >> Requiring this level of hardware design >> is generally outside the scope of the language standard. Unless this >> is a proposal for an IEEE standard, I would prefer that it be removed >> from this section. > > A significant number of Fortran users would prefer that it not be removed! > Well, so far the only ones I've ever encountered were the 2 (3?) who have sent emails in this thread. But then there has been evidence before that Malcolm and I live in different programming universes. In recent memory, I've only encountered one case of harmful integer overflow, and that occurred in converting a large real value to integer and was caught by the IEEE hardware traps. Of course, there are numerous cases, almost all related to user-written random number generators, where overflow of integer multiply is intentional. For those cases, enabling a check would cause the program to stop working. > Anyway, it is not outside the scope of the Fortran standard. Nick has already > pointed out that COBOL requires it. Furthermore, the Fortran standard itself > already requires detection of a nonzero number of runtime errors, and has done > so since Fortran 90. We have added addition error detection requirements in > every revision. True. But this would be a costly addition (except for Malcolm if he already supports it) to catch errors that I never see occurring. The cost seems too high for the potential benefit. Cheers, Bill > > Although this bullet point appears first, the list appears to be essentially > unordered with respect to either difficulty or priority. I would expect that > some of the other bullet points would be considered more tractable and higher > priority, or "lower-hanging" in colloquial; that does not mean that this > suggestion for consideration does not belong any more than the suggestion for > consideration of subscript error detection mandation is out of order. > > Cheers, > -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101