From J.L.Schonfelder@liverpool.ac.uk Fri Jul 8 10:38:23 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA01422 (5.65c8/IDA-1.4.4j for ); Fri, 8 Jul 1994 10:39:08 +0200 Received: from liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <06988-0@mailhub.liverpool.ac.uk>; Fri, 8 Jul 1994 09:38:24 +0100 From: "Dr.J.L.Schonfelder" Message-Id: <199407080838.JAA24508@uxg.liv.ac.uk> Subject: varying string ballot responces To: SC22WG5@dkuug.dk (SC22/WG5 members) Date: Fri, 8 Jul 1994 09:38:23 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3222 X-Charset: ASCII X-Char-Esc: 29 Here is my draft responce to the ballot comments. I hope you find this useful and acceptable. It is the best I can do in the time available. I depart for a visit to Australia as of today so I will not be able to do anything further. and will not be at the Ed. meetings either. ----------------------------------------------------------------------------- To: WG5 From: Lawrie Schonfelder Re: Varying String Final Ballot Responces Date: July 5, 1994 There were three National Bodies who provided comments attached to their YES ballots. These were: France, Holland, and UK. Both Holland and the UK pointed out a deficiency with the GET procedure as currently defined. When used with the set argument there is no way to retrieve the actual terminator character read from the input record. Two possible ways of correcting this deficiency were proposed and circulated to WG5 be e-mail for comment. Very little responce was elicited but the balance of this was to favour adding an optional separator argument to the relevant versions of the GET procedure which if present will be used to return the actual terminator character found. This has been done and the necessary additions to the text of the standard made and the GET procedures in the illustrative module modified accordingly. The French made three comments. The first comment was to point out the minor peculiarity of overloading intrinsic procedures like ICHAR which necessarily take arguments that are a single character to permit an argument that is a varying string containing only a single character. This feature was debated at length by WG5 on more than one occasion and a positive decision taken to include these slightly strange overloads. No further action is proposed in responce to this comment. The second French comment was questioning the distinction between reading an empty line and an end-of-file condition. This appears to more a request to add a capability to the main Fortran language than a comment on the varying string auxilliary standard. It would also appear to be based on a misunderstanding. The execution of a GET on an empty record would indeed produce a zero length string and a negative value for iostat. This negative value would be that required to represent the end-of-record condition, not the different negative value that would result from the attempt to read past the end-of-file. Both this standard and the main language standard require the iostat values for EOF and EOR to be negative and different but otherwise do not specify the actual values. It looks as if this comment is a request that the primary language include some mechanism to inquire as to what the values are that a particular processor uses. A perfectly reasonable request but not appropriate for this standard. No action is proposed. The third of these pointed out that the reference to ISO/IEC 646 : 1983 should have been to the current revision dated 1991. The corrections have been made. -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk