Path: utzoo!attcan!uunet!snorkelwacker!usc!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!harriett!hirchert From: hirchert@harriett.ncsa.uiuc.edu (Kurt Hirchert) Newsgroups: comp.lang.fortran Subject: Re: record length for direct access files (corrected) Message-ID: <1990Oct3.160641.19506@ux1.cso.uiuc.edu> Date: 3 Oct 90 16:06:41 GMT References: <2146@key.COM> <2151@key.COM> <2152@key.COM> Sender: news@ux1.cso.uiuc.edu (News) Reply-To: hirchert@harriett.ncsa.uiuc.edu (Kurt Hirchert) Organization: National Center for Supercomputing Applications Lines: 73 In article <2152@key.COM> sjc@key.COM (Steve Correll) writes: >1. Is there anything in the Fortran 90 standard which forbids the following? > (The intent is to write an element-count "icnt" followed by that number of > elements of an array). > > dimension x(5000) > integer record_length > ... > read *, icnt > inquire(iolength=record_length) icnt, (x(j), j=1, icnt) > open(unit=io, file='myfile', form='unformatted', & > access='direct', recl=record_length, & > status='new', action='readwrite') > write(unit=io,rec=1) icnt, (x(j), j=1, icnt) > close(unit=io) The example looks OK to me. > >2. If that example is legal, then I believe it's not possible to compute at > compilation time how long the records will actually be. Is it intended that > the INQUIRE/IOLENGTH construct be computed at execution time rather than at > compilation time? Perhaps "intended" is too strong a word. There is no intent to discourage compile-time evaluation of INQUIRE(IOLENGTH= ), but it was recognized that this will not always be possible. > >3. Now suppose another program wants to read the file back in. Is there > anything in the Fortran 90 standard that forbids the following example? > > inquire(iolength=record_length) icnt, (x(j), j=1, icnt) > open(unit=ii, file='myfile', form='unformatted', & > access='direct', recl=record_length, & > status='old', action='readwrite', iostat=iostat) > read(unit=ii) icnt, (x(j), j=1, icnt) It depends on how literally I am to take your example. As written, icnt is undefined, so this constitutes a reference to an undefined variable. > >4. If that example is legal, then is the compiler allowed to give the "wrong" > answer by using the value of "icnt" at the time of the INQUIRE/IOLENGTH > statement even though that value will change during the READ statement? > S8.115 section 9.6.3 says INQUIRE/IOLENGTH computes a suitable record length > for "input/output statements with the same input/output list", as if it were > always possible to do so correctly. It's all a question of what you consider "the same input/output list". As a practical matter in this example, the value of record_length returned for any particular value of icnt will be sufficient to hold records corresponding to using that icnt _or_a_smaller_one_ in the read and write statements. To put it another way, INQUIRE(IOLENGTH= ) is a tool for portably determining record lengths, not a panacea to banish all possible problems in this area. The limitations inherent in a fixed record size remain. > >(Incidentally, a less perverse example which _is_ computable at compilation >time, but not trivially so, is the following, which writes a triangular portion >of a matrix. Any guesses on how many Fortran 90 compilers will get this stuff >wrong the first time out?) > > dimension x(5000, 5000) > inquire(iolength=il) ((x(i, j), i=1, j), j=1, 5000) > ... > write(unit=io) ((x(i, j), i=1, j), j=1, 5000) My guess would be that many compilers will simply punt and do it at execution time. On the other hand, won't compilers have to deal with similar constructs in DATA statements? (My /S8.115 isn't handy, so I can't check this myself right now.) If they can get it right in the DATA statement, why should they get it wrong in the INQUIRE? -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications