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

[Bill Long]

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