From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Jan 17 00:15:27 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 1BBE0356C9D; Thu, 17 Jan 2013 00:15:27 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by www.open-std.org (Postfix) with ESMTP id 3245C3568A7 for ; Thu, 17 Jan 2013 00:15:25 +0100 (CET) Received: from CFWEX01.americas.cray.com ([136.162.34.11]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUPcYxEeeDtacwqPevdgRq2Z+BPU7+SMH@postini.com; Wed, 16 Jan 2013 13:16:54 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 15:14:13 -0600 Message-ID: <50F71829.30302@cray.com> Date: Wed, 16 Jan 2013 15:14:17 -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.4900) [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> <20130116191114.A6A75356A2B@www.open-std.org> <20130116223411.D135F356A2B@www.open-std.org> In-Reply-To: <20130116223411.D135F356A2B@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/16/13 2:35 PM, N.M. Maclaren wrote: > On Jan 16 2013, Bill Long wrote: >> >> 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. > > Do none of the codes you see ever include fragments like the following? > > SUBROUTINE weeble (arg) > REAL(KIND=KIND(0.0D0)) :: arg(:,:) > REAL(KIND=KIND(0.0D0)) :: scratch(UBOUND(arg,1)*(UBOUND(arg,1)+1)/2) > > Being caught out by default integers being large enough for any single > dimension but not the total size of an array, and accidentally using a > calculation that creates the latter, is a very common mistake in all of > Fortran, C and C++. > For Fortran, and a program with arrays this large, users would instinctively set a compiler switch to make 64-bit integers the default. This avoids other problems later, like the kind of the subscript you use to run through the array scratch. Of course, there is a narrow window where small integers would work, but that's a bit contrived. For C and C++ I would expect the relevant variables to be declared size_t, which should avoid the problem. Cheers, Bill > > Regards, > Nick Maclaren. > > _______________________________________________ > J3 mailing list > J3@mailman.j3-fortran.org > http://mailman.j3-fortran.org/mailman/listinfo/j3 > -- 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