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

Wed Jan 16 17:15:49 EST 2013

Sorry the program ended up without line breaks.

here is a url

http://www.fortranplus.co.uk/resources/ch0504_2.f90

-----Original Message-----
From: j3-bounces at mailman.j3-fortran.org
[mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Ian Chivers
Sent: 16 January 2013 22:13
To: longb at cray.com; 'sc22wg5'
Subject: (j3.2006) (SC22WG5.4902) RE: [ukfortran] Comment on a comment on
the WG5 letterballot on N1947

Integer overflow
================

Hardware support
----------------

Whilst the current IEEE standard doesn't say anything about integer
arithmetic there is nothing to stop hardware manufacturers adding additional
functionality to their hardware.

There have also been processors that have supported integer overflow
detection. 

I have a variety of old hardware manuals (in the loft) that document 4 bit,
8 bit, 16 bit etc processors. I could dig them out and provide specific
information in this area. :-(

Software support
----------------

I've seen software support for integer overflow detection in a number of
Fortran compilers, so this isn't new.

The CDC Pascal and Modula 2 languages (which I used and or supported whilst
working at Imperial College 1978-1986) had ranges and sub-ranges for
integers and it was possible with both of these compilers to switch range
and sub range checking on.

You could for example do something similar to the following

  day    [1..31]
  month  [1..12]
  year   [1900..2000]

and trap invalid days, month and year values.

So compiler technology was available in the 1970s and 1980s to do this.

Simple Fortran example
----------------------

The following trivial program illustrates integer overflow on most
compilers.

So Bill's claim that integer overflow
never creates problems is not a claim
I would agree with.

program ch0504
implicit none
real :: Light_Minute, Distance, Elapse
integer :: Minute, Second
real , parameter :: Light_Year=9.46*10**12 ! Light_year : Distance travelled
by light ! in one year in km ! Light_minute : Distance travelled by light !
in one minute in km ! Distance : Distance from sun to earth in km ! Elapse :
Time taken to travel a ! distance (Distance) in minutes ! Minute : integer
number part of elapse ! Second : integer number of seconds ! equivalent to
fractional part of elapse !
   Light_minute = Light_Year/(365.25 * 24.0 * 60.0)
   Distance = 150.0 * 10 ** 6
   Elapse = Distance / Light_minute
   Minute = Elapse
   Second = (Elapse - Minute) * 60
   print *,' Light takes ' , Minute,' Minutes'
   print *,' ' , Second,' Seconds'
   print *,' To reach the earth from the sun'
end program ch0504

I personally want a compile time diagnostic to tell me if something is
wrong.

Failing that a clear run time error.

I worked in User Support from 1978-2001 helping debug other peoples
programs.
I've spent quite a lot of time chasing bugs in peoples code.

-----Original Message-----
From: ukfortran [mailto:ukfortran-bounces at lists.accu.org] On Behalf Of Bill
Long
Sent: 16 January 2013 17:07
To: sc22wg5
Subject: [ukfortran] (SC22WG5.4899) (j3.2006) Comment on a comment on the
WG5 letterballot on N1947

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 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

_______________________________________________
ukfortran mailing list
http://lists.accu.org/mailman/listinfo/ukfortran

_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3