lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (10/15/89)
Can someone enlighten me as to what the ANSI F77 spec has to say
about where a file pointer sits immediately after an open?
We have looked at the documentation for a number of f77 compilers --
each one seems to have it's own idea of where to position the pointer.
Assuming the following code fragment, what does the ANSI standard
say about positioning the file pointer? (tmedata is an existing file
with data in it.)
program main
.
.
open(unit = 10, file = 'tmedata')
.
.
.
--
Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University
{alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA
"I think every man should have a wife. You can't blame
everything on the government." -- Jed Clampettjohnl@esegue.segue.boston.ma.us (John R. Levine) (10/15/89)
In article <1162@atha.AthabascaU.CA> lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes: >Can someone enlighten me as to what the ANSI F77 spec has to say >about where a file pointer sits immediately after an open? It doesn't say anything (and I just reread the section on OPEN for the zillionth time, just to be sure.) A standard conforming processor could position the file at the beginning, at the end, or at the 17th record. It could pick a different position every time. If you think this is stupid, then you understand the essence of F77 file processing. There is a lot of other stupid stuff, too, for example in an OPEN you can say whether the file is NEW or OLD, presumably so it can slap your wrist if you guessed wrong, but you can't say whether you intend to read, write, or both. I have written an F77 I/O system for Unix, and the backflips I had to go through to implementing it weren't pretty. When the user did an OPEN, I had to save the information and not really open the file until the first READ or WRITE, since opening an OLD file might mean that the user wanted to read it or wanted to append to it. There is no portable way to append to a file other than opening it, rewinding it, reading to the end, backspacing over the EOF record that the standard says is at the end of each file, and then writing. My impression is that there was a lot of arguing in the F77 committee among vendors with real file systems, vendors with no file systems, and vendors like IBM which were somewhere in between. They ended up with a compromise that is full of features that are so vague as to be useless. I hope F8x is better, I await my copy of the standard eagerly. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl Massachusetts has over 100,000 unlicensed drivers. -The Globe
mcdonald@uxe.cso.uiuc.edu (10/15/89)
/* Written 2:19 pm Oct 14, 1989 by lyndon@cs.AthabascaU.CA in uxe.cso.uiuc.edu:comp.lang.fortran */
/* ---------- "Position in file after open?" ---------- */
Can someone enlighten me as to what the ANSI F77 spec has to say
about where a file pointer sits immediately after an open?
We have looked at the documentation for a number of f77 compilers --
each one seems to have it's own idea of where to position the pointer.
Assuming the following code fragment, what does the ANSI standard
say about positioning the file pointer? (tmedata is an existing file
with data in it.)
program main
.
.
open(unit = 10, file = 'tmedata')
.
.
.
/* End of text from uxe.cso.uiuc.edu:comp.lang.fortran */
Okay, what about this:
OPEN(UNIT = 9,FILE = 'ALREADYEXISTS', STATUS = 'UNKNOWN')
REWIND(9)
Is "unknown" a standard contruct or not? If so, should this always
begin writing at the begiining of file, overwriting anything alreay
there?
IF not legal, is there any legal way to overwrite a file besides
attempting to open it for read, and if there closing it with a
delete specifier, themn opening a new file for write? That appears
to be the only way to do it in an oddball Fortran compiler I have
(MicroWay NDPC for the 386).
Doug McDonalddricejb@drilex.UUCP (Craig Jackson drilex1) (10/16/89)
In article <1989Oct14.233757.8471@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: >In article <1162@atha.AthabascaU.CA> lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes: >>Can someone enlighten me as to what the ANSI F77 spec has to say >>about where a file pointer sits immediately after an open? > >It doesn't say anything (and I just reread the section on OPEN for the >zillionth time, just to be sure.) A standard conforming processor could >position the file at the beginning, at the end, or at the 17th record. It >could pick a different position every time. If you think this is stupid, >then you understand the essence of F77 file processing. I believe that the standard is silent on this point so that things like JCL's DISP=MOD are allowed to have their correct semantics. In JCL, if you say DISP=NEW on an output file, a new file is created. If you say DISP=MOD, an old file is appended to. All of this happens outside the actual Fortran program. These things are useful in a batch environment if you don't want a lot of file positioning code in your application. >My impression is that there was a lot of arguing in the F77 committee >among vendors with real file systems, vendors with no file systems, and >vendors like IBM which were somewhere in between. They ended up with a >compromise that is full of features that are so vague as to be useless. >I hope F8x is better, I await my copy of the standard eagerly. I think that F8x does address this subject somewhat better, but I think that there are still provisions which allow external positioning for the batch people. >-- >John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 >johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
johnl@esegue.segue.boston.ma.us (John R. Levine) (10/16/89)
In article <50500152@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > OPEN(UNIT = 9,FILE = 'ALREADYEXISTS', STATUS = 'UNKNOWN') > REWIND(9) > >Is "unknown" a standard contruct or not? If so, should this always >begin writing at the begiining of file, overwriting anything alreay >there? Yes, UNKNOWN is actually in the standard, the other two options being NEW and OLD which say that the file must not or must exist. You cannot say in the OPEN statement whether your intention is to read or to write. REWIND positions a file at its initial point. (This is all from X3.9-1978, section 12.) It seems to me that this is as portable a way as any to open a file either for reading or for writing. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl Massachusetts has over 100,000 unlicensed drivers. -The Globe
khb%chiba@Sun.COM (Keith Bierman - SPD Advanced Languages) (10/17/89)
In article <50500152@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > >/* Written 2:19 pm Oct 14, 1989 by lyndon@cs.AthabascaU.CA in uxe.cso.uiuc.edu:comp.lang.fortran */ >/* ---------- "Position in file after open?" ---------- */ >Can someone enlighten me as to what the ANSI F77 spec has to say >about where a file pointer sits immediately after an open? As is moderately well known, this is a "feature" of the '77 standard. While it is "obvious" that a freshly opened file should be positioned at the start, there is a legend that at least one popular compiler positions to the end of file just to prove to customers how bad the standard is ... > > > OPEN(UNIT = 9,FILE = 'ALREADYEXISTS', STATUS = 'UNKNOWN') > REWIND(9) > >Is "unknown" a standard contruct or not? If so, should this always Unknown is perfectly standard ... but it doesn't address the positioning question at all. The f8x standard does. OPEN(UNIT = 9,FILE = 'ALREADYEXISTS', STATUS = 'UNKNOWN', & POSITION = pos) where pos is a character expression which ignoring trailing blanks and converting any lower-case letters to upper-case, has the value ASIS, REWIND, or APPEND. The default (in F8x as currently drafted) is to open a file to its start. While this is what nearly everyuser ever asked wants ... it has the _potential_ of breaking some outlandish program which was never ported to another machine (as most vendors learned that users really don't like to have to follow every open with a rewind ... and consider such behavior a bug) ... >begin writing at the begiining of file, overwriting anything alreay >there? > >IF not legal, is there any legal way to overwrite a file besides >attempting to open it for read, and if there closing it with a >delete specifier, themn opening a new file for write? That appears >to be the only way to do it in an oddball Fortran compiler I have >(MicroWay NDPC for the 386). > >Doug McDonald I don't understand the MicroWay problem ... doesn't the open/rewind/write work on that system ? If not, (a) file a bug report, (b) open, close (status=delete), open ? Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO"
sjc@key.COM (Steve Correll) (10/17/89)
lyndon@cs.AthabascaU.CA writes:: > Can someone enlighten me as to what the ANSI F77 spec has to say > about where a file pointer sits immediately after an open? In the Fortran77 standard, this is "processor dependent". mcdonald@uxe.cso.uiuc.edu writes: > Is "unknown" a standard contruct or not?...is there any legal way to > overwrite a file besides attempting to open it for read, and if there > closing it with a delete specifier, then opening a new file for write? STATUS='UNKNOWN' is standard Fortran77, but its effect is "processor dependent". johnl@esegue.segue.boston.ma.us writes: > I hope F8x is better, I await my copy of the standard eagerly. The Fortran88 draft provides STATUS='replace': if the file exists, you delete it; then you always create a new one. This raises interesting questions on a system (e.g. Unix) where deleting an old file and creating a new one is _not_ the same as opening the old file and truncating it to become empty. In Unix, in the former case, the "inode" will in general change, and any file descriptors already open on the old file will continue to see the contents of the old file without error or warning. If some implementors choose deletion and others truncation, programs which open the same file on multiple logical units may not be portable (though I suppose that without control over buffering, such programs are not portable anyway). The draft OPEN also provides POSITION={'ASIS','REWIND','APPEND'} to dictate the position of the file; and ACTION={'READ','WRITE','READWRITE'}. The latter doesn't solve any implementation problems which you may have encountered in Fortran77, since you must still provide Fortran77 behavior in its absence. -- ...{sun,pyramid}!pacbell!key!sjc Steve Correll
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (10/19/89)
In article <126396@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - SPD Advanced Languages) writes: >As is moderately well known, this is a "feature" of the '77 standard. >While it is "obvious" that a freshly opened file should be positioned >at the start, there is a legend that at least one popular compiler >positions to the end of file just to prove to customers how bad the >standard is ... From IBM's _VS FORTRAN Application Programming: Language Reference_: "After a sucessful open ... the file is not repositioned at the beginning" So much for legend :-) The f77 compiler from the UNIX SVR3.1 porting base explicitly positions to the end as well. Are there any other languages that come to mind that exhibit this type of behavior? -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA The Connector is the Notwork.
khb%chiba@Sun.COM (Keith Bierman - SPD Advanced Languages) (10/20/89)
In article <1177@atha.AthabascaU.CA> lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes: >In article <126396@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - SPD Advanced Languages) writes: >>As is moderately well known, this is a "feature" of the '77 standard. >>While it is "obvious" that a freshly opened file should be positioned >>at the start, there is a legend that at least one popular compiler >>positions to the end of file just to prove to customers how bad the >>standard is ... > >From IBM's _VS FORTRAN Application Programming: Language Reference_: > > "After a sucessful open ... the file is not repositioned > at the beginning" > >So much for legend :-) No the question of _why_ is addressed by the legend. > >The f77 compiler from the UNIX SVR3.1 porting base explicitly >positions The story is that Stu Feldman, author of the "portable unix f77" did this explicitly. Sensible vendors fix this. >type of behavior? One hopes not ... but where one does ... others are sure to follow. Anyone have other VS languages manuals handy ? Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO" "There is NO defense against the attack of the KILLER MICROS!" Eugene Brooks
hirchert@uxe.cso.uiuc.edu (10/20/89)
1. The FORTRAN 77 standard does not specify the position of a file after an
OPEN. This was done intentionally in order to allow processors the freedom
to support external prepositioning of files (e.g., the MOD disposition in
IBM JCL which positions at the end of a file or the way many systems handle
multi-file tapes).
2. It was the FORTRAN committee's intention that processors that did not
support prepositioning would position at the beginning. However, one
famous family of implementations positions files at the end. Depending
on who you ask, the reason for this was
a. to provide a useful alternative that could not be easily achieved
otherwise
b. to prove that there was a hole in the standard
3. The proposed Fortran 8x standard includes a keyword in the OPEN statement
for specifying initial position. Contrary to what has been posted earlier,
the default is 'ASIS', allowing Fortran 8x processors to behave
consistently with their FORTRAN 77 predecessors. However, we can still
hope that processors without prepositioning treat 'ASIS' as synonymous with
'REWIND' rather than 'APPEND'.