(j3.2006) (SC22WG5.4901) [ukfortran] Comment on a comment on the WG5 letterballot on N1947

[Bill Long]

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 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
>

-- 
Bill Long                                           longb at 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