From bleikamp@mozart.convex.com Mon Jan 29 20:46:31 1996 Received: from convex.convex.com (convex.convex.com [130.168.1.1]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id UAA16655 for ; Mon, 29 Jan 1996 20:46:02 +0100 Received: from mozart.convex.com by convex.convex.com (8.6.4.2/1.35) id NAA16128; Mon, 29 Jan 1996 13:44:38 -0600 Received: from localhost by mozart.convex.com (8.6.4/1.28) id NAA17214; Mon, 29 Jan 1996 13:44:40 -0600 From: bleikamp@mozart.convex.com (Richard Bleikamp) Message-Id: <199601291944.NAA17214@mozart.convex.com> Subject: Re: (SC22WG5.1017) (x3j3.1996-37) fodder for meeting To: Craig.Dedo@mixcom.com (Craig Dedo) Date: Mon, 29 Jan 96 13:44:40 CST Cc: Keith.Bierman@eng.sun.com, sc22wg5@dkuug.dk In-Reply-To: <199601291915.UAA15975@dkuug.dk>; from "Craig Dedo" at Jan 29, 96 1:19 pm X-Mailer: ELM [version 2.3 PL11] 'Craig Dedo' wrote: > > On Mon, 29 Jan 96, Keith.Bierman@eng.sun.com wrote: > ...... > > > The NEXTREC= specifier of an INQUIRE statement is required to be > > a scalar-default-int-variable. With large file systems, it might > > be impossible to store the correct value of NEXTREC= in a default > > INTEGER variable. If a larger integer type is available, it would > > be nice to be able to use it. Perhaps this is an issue X3J3 should > > address in Fortran 96. > > >Of course a processor could allow use of non-default kinds in nextrec > >as an extension ... but such code would be flagged as non-standard > >complying .... > > [ deleted information on historic large problems] > > >I don't have text proposed at this juncture ... but a "straw vote" > >might be handy. Does anyone think this is a problem that ought to be > >fixed in this release? > > Absolutely _YES_. > > I propose a simple solution. Allow ANY kind of INTEGER in any I/O specifier that requires an INTEGER data object. I.e., a processor would be required to accept any INTEGER data object. Failure to do so would not be standard conforming. This allows a programmer to circumvent the problem, but NOT in a portable manner. Since different processers support different KIND #s, and not all processors support larger integers (8 bytes that is), there probably is no simple change to allow this "fix" in a portable manner. You also need to define how the processor is to behave when the user passes in a small (1 byte) integer, and the value to be assigned overflows. When only default sized integers were allowed, such an overflow meant that the program was probably hosed anyways, and aborting wasa appropriate. But when you allow users to pass in 1 byte integers for these fields, like IOSTAT, you probably want to reconsider the desired behavior when the values are too large. rich