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

[Craig Dedo]

	Like others, I disagree with Bill Long's position.  See below (at end).

> -----Original Message-----
> From: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org]
> On Behalf Of Bill Long
> Sent: Wednesday, January 16, 2013 11:07
> To: sc22wg5
> Subject: (j3.2006) (SC22WG5.4899) [ukfortran] 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
> 
	<snip>
> 
> --
> 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

	Although I do not have any expertise in hardware architecture or compiler design,
I have reason to believe that providing for detection of integer overflow does not
necessarily need to be difficult or expensive.  Apparently, this kind of work has already
been done in several other contexts.

	1.  The OpenVMS operating system provides for detection of many different kinds of
overflow, not all of them through hardware detection.  This includes detection of such
conditions as buffer overflow, character string overflow, facility table overflow, and
index area overflow.  Overflow detection is done by the OS.  Many of these are detected in
the OpenVMS System Services facility, one of the oldest components of the OS.  In the case
of integer overflow, the specific system message is:
%SYSTEM-F-INTOVF, arithmetic trap, integer overflow at PC='xxxxxxxx', PSL='xxxxxxxx'

The explanation from the Message Utility Reference is:
Facility: SYSTEM, System Services
Explanation: An exception condition occurred as a result of an integer overflow.
User Action: Examine the PC location displayed in the message and check the program
listing to verify that operands or variables are specified correctly.

Reference:  OpenVMS System Messages and Recovery Procedures Reference Manual: A-L, p. 331.
Publication Date:  May 1993.  In later versions of OpenVMS, information about condition
messages has been contained online as part of the OpenVMS HELP Utility.

	2.  Detection of integer overflow conditions was part of John Reid's ENABLE block
proposal in 1994.  All versions of these proposals included detection of these conditions
within an ENABLE block:  INTEGER_OVERFLOW and INTEGER_DIVIDE_BY_ZERO.  For detailed
information, see these X3J3 papers:  94-020, 94-086, 94-095r1, 94-099, 94-147r3, and
94-258r4.

Sincerely,
Craig T. Dedo
17130 W. Burleigh Place
P. O. Box 423                  Mobile Phone:  (414) 412-5869
Brookfield, WI   53008-0423    E-mail:  <craig at ctdedo.com>
USA
Linked-In:  http://www.linkedin.com/in/craigdedo