From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org  Sun Jan 13 22:06:32 2013
Return-Path: <owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www.open-std.org
Received: by www.open-std.org (Postfix, from userid 521)
	id 5CBB4356BC8; Sun, 13 Jan 2013 22:06:32 +0100 (CET)
Delivered-To: sc22wg5@open-std.org
Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150])
	by www.open-std.org (Postfix) with ESMTP id C710C356B6E
	for <sc22wg5@open-std.org>; Sun, 13 Jan 2013 22:06:31 +0100 (CET)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:35867)
	by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25)
	with esmtpa (EXTERNAL:nmm1) id 1TuSuU-0000im-qK (Exim 4.72)
	(return-path <nmm1@hermes.cam.ac.uk>); Sun, 13 Jan 2013 19:07:58 +0000
Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk)
	with local (PRAYER:nmm1) id 1TuSuU-0007es-4q (Exim 4.72)
	(return-path <nmm1@hermes.cam.ac.uk>); Sun, 13 Jan 2013 19:07:58 +0000
Received: from [146.90.108.249] by webmail.hermes.cam.ac.uk
	with HTTP (Prayer-1.3.5); 13 Jan 2013 19:07:58 +0000
Date: 13 Jan 2013 19:07:58 +0000
From: "N.M. Maclaren" <nmm1@cam.ac.uk>
To: WG5 <sc22wg5@open-std.org>
Subject: Comment on a comment on the WG5 letter ballot on N1947
Message-ID: <Prayer.1.3.5.1301131907580.20643@hermes-1.csi.cam.ac.uk>
In-Reply-To: <20130108205438.50F4E356B56@www.open-std.org>
References: <20130108205438.50F4E356B56@www.open-std.org>
X-Mailer: Prayer v1.3.5
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

This is irrelevant to the vote, and is NOT intended to be added to it,
but might be considered by the editor and vulnerabilities group.  I am
merely dissenting from one technical point.

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

This is overstated, because hardware support is NOT needed, and the
feature is specified by at least Cobol.  It does degrade performance,
though by much less than is usually claimed, as has been found in many
compilers on many architectures.   There is a significant minority of
Fortran users who favour this facility being added, at least as an
option.  All I am saying is that the requirement 'should be considered'
is reasonable.


Regards,
Nick Maclaren.



