From owner-sc22wg5@dkuug.dk Wed Jan 8 22:30:47 2003 Received: (from majordom@localhost) by dkuug.dk (8.9.2/8.9.2) id WAA36657 for sc22wg5-domo; Wed, 8 Jan 2003 22:30:47 +0100 (CET) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id WAA36652 for ; Wed, 8 Jan 2003 22:30:45 +0100 (CET) (envelope-from maine@altair.dfrc.nasa.gov) Received: from mail.dfrc.nasa.gov by mailhub.dfrc.nasa.gov with ESMTP for sc22wg5@dkuug.dk; Wed, 8 Jan 2003 13:01:16 -0800 Received: from altair.dfrc.nasa.gov ([130.134.164.107]) by mail.dfrc.nasa.gov (Post.Office MTA v3.5.3 release 223 ID# 0-71686U2500L200S0V35) with ESMTP id gov for ; Wed, 8 Jan 2003 12:31:43 -0800 Received: from altair.dfrc.nasa.gov (localhost.localdomain [127.0.0.1]) by altair.dfrc.nasa.gov (8.12.5/8.12.5) with ESMTP id h08KVjL1031565 for ; Wed, 8 Jan 2003 12:31:45 -0800 Received: (from maine@localhost) by altair.dfrc.nasa.gov (8.12.5/8.12.5/Submit) id h08KVjaT031561; Wed, 8 Jan 2003 12:31:45 -0800 From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <15900.35505.270507.190587@altair.dfrc.nasa.gov> Date: Wed, 8 Jan 2003 12:31:45 -0800 To: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2665) A partial comment about "Status of Repositoryitems" In-Reply-To: <3E1C59BE.7080501@cray.com> References: <200301080922.KAA26798@dkuug.dk> <3E1C59BE.7080501@cray.com> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Bill Long writes: > Ironically, Bernard's comment strikes directly at the problem, but his > solution is in the wrong direction. Without the "of the constant > IOSTAT_END (13.8.3.2.1)" the statement is correct with "a" but wrong > with "the". I disagree (as I did at the J3 meeting). And although J3 voted to suggest changing the IOSTAT_END constant to a function in order to accomodate the implementations you mention, this suggestion did not (as far as I'm aware) include actually changing the requirement that there be a single value. I maintain that f95 requires a single value and that any processor that returns multiple values is already non-conforming. Perhaps we should have a formal interp request on the question if there is any doubt or disagreement on it. Nor have I seen a formal proposal to change this requirement for f2k. I've seen surprised looks when I pointed out the requirement in f95, but I didn't see a formal proposal to change it (in a manner that would break compatability with old codes that assumed the f95 standard was followed). The use of a function instead of a named constant can facilitate things for vendors who might violate that requirement of the standard, but it doesn't keep it from being a violation. I do not recall any vote that actually suggested that we change the requirement. Of course, that may have been because people didn't realize it was a violation until I pointed it out (and quite likely didn't have time to study my claim on the floor in real time). You might discount my interpretation of the vote, insomuch as I was in a minority anyway, but the only vote I recall on this was to change the IOSTAT_END constant to a function. -- Richard Maine | Good judgment comes from experience; maine@altair.dfrc.nasa.gov | experience comes from bad judgment. | -- Mark Twain