From owner-sc22wg5@open-std.org  Thu Jan 22 10:57:57 2009
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom7
Delivered-To: sc22wg5-dom7@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id 035E5CA3439; Thu, 22 Jan 2009 10:57:57 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131])
	by www2.open-std.org (Postfix) with ESMTP id 75FFDCA3434
	for <sc22wg5@open-std.org>; Thu, 22 Jan 2009 10:57:55 +0100 (CET)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:41974)
	by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25)
	with esmtpa (EXTERNAL:nmm1) id 1LPwJu-00084p-4g (Exim 4.70) for sc22wg5@open-std.org
	(return-path <nmm1@hermes.cam.ac.uk>); Thu, 22 Jan 2009 09:57:54 +0000
Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk)
	with local (PRAYER:nmm1) id 1LPwJu-0000Nz-EB (Exim 4.67) for sc22wg5@open-std.org
	(return-path <nmm1@hermes.cam.ac.uk>); Thu, 22 Jan 2009 09:57:54 +0000
Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk
	with HTTP (Prayer-1.3.1); 22 Jan 2009 09:57:54 +0000
Date: 22 Jan 2009 09:57:54 +0000
From: "N.M. Maclaren" <nmm1@cam.ac.uk>
To: sc22wg5 <sc22wg5@open-std.org>
Subject: Re: [ukfortran] (SC22WG5.3883) (j3.2006) WG5 Ballot 6 (N1765)
Message-ID: <Prayer.1.3.1.0901220957540.28472@hermes-2.csi.cam.ac.uk>
In-Reply-To: <20090122041335.1FB2FC178D9@www2.open-std.org>
References: <20090122033039.95FC7C178D9@www2.open-std.org>
 <20090122041335.1FB2FC178D9@www2.open-std.org>
X-Mailer: Prayer v1.3.1
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

On Jan 22 2009, Robert Corbett wrote:
>Van Snyder wrote:
>
>> F03/0117: Making the whole file undefined seems a bit harsh.  Couldn't
>> this have been "the record being written when the program is
>> terminated?"
>
>That change would place a burden on I/O buffering that would
>hurt the performance of many implementations.  For some types
>of devices, it might even be impossible to implement.

Actually, I believe that all of those points apply only to poorly 
implemented I/O systems, and a suitably milder constraint would be 
possible. I am nowhere near omniscient on I/O systems, but have used a wide 
variety, and know of none that couldn't support Van's proposal (in 
principle).

Unfortunately, it would need quite a lot of wording, because formatted I/O 
allows multiple records to be written in one statement and stream files 
muddy the issue considerably. I doubt that it is worth the effort.

Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679



