Author |
Message |
Count Dracu #1 / 19
|
Opening a file already open
If a program attempts to open a file that is already open, different compilers take different actions. The test program below shows the details of the opening conditions. The results I see are AIX xlf90 : File cannot be opened the second time. HPUX f90 : File cannot be opened the second time. Lahey 95 : File is opened normally the second time. DVF 6.0 : File is opened normally the second time. Does the F90 standard leave this up to the compiler? I think the two Unix compilers above make the more reasonable choice; I don't know if this is the choice made by Sun or SGI. program open_file_test integer :: ios open (unit = 12, status = "UNKNOWN", file = "garbage.dat", action = "READ", iostat = ios) if (ios == 0) then write (unit = *, fmt = *) "File garbage.dat opened" else write (unit = *, fmt = *) "File garbage.dat cannot be opened" end if open (unit = 16, status = "UNKNOWN", file = "garbage.dat", action = "WRITE", iostat = ios) if (ios == 0) then write (unit = *, fmt = *) "File garbage.dat opened" else write (unit = *, fmt = *) "File garbage.dat cannot be opened" end if end program open_file_test -- _________________________________________________________________________
_________________________________________________________________________
|
Mon, 17 Feb 2003 21:37:08 GMT |
|
|
Michael Metcal #2 / 19
|
Opening a file already open
Does the F90 standard leave this up to the compiler? ====================================================== On page 225 of "fortran 90/95 Explained" appears: "A file already connected to one unit must not be specified for connection to another unit." Not the standard, but I can find it faster. Regards, Mike Metcalf --
|
Mon, 17 Feb 2003 22:14:08 GMT |
|
|
Steve Lione #3 / 19
|
Opening a file already open
Quote:
>If a program attempts to open a file that is already open, >different compilers take different actions.
Note that the standard imposes restrictions on what the program may or may not do. A standard-conforming program may not open the same external file on two or more units at the same time. However, a "processor" (compiler/run-time/OS) may allow this as an extension. Don't depend on it to work everywhere. Note that many operating systems have the concept of "sharing" a file, and have defined semantics for multiple I/O streams to the same file. You may need some platform-specific options to get the behavior you want.
Fortran Engineering Compaq Computer Corporation, Nashua NH Compaq Fortran web site: http://www.compaq.com/fortran
|
Mon, 17 Feb 2003 22:45:49 GMT |
|
|
James Gile #4 / 19
|
Opening a file already open
Quote: >Does the F90 standard leave this up to the compiler? >====================================================== >On page 225 of "Fortran 90/95 Explained" appears: "A file already >connected to one unit must not be specified for connection to >another unit." Not the standard, but I can find it faster.
It's section 9.3.4 of both F90 and F95: If a file is already connected to a unit, execution of an OPEN statement on that file and a different unit is not permitted. -- J. Giles
|
Mon, 17 Feb 2003 22:26:43 GMT |
|
|
Richard Main #5 / 19
|
Opening a file already open
Quote:
> If a program attempts to open a file that is already open, > different compilers take different actions. The test program > below shows the details of the opening conditions. The results > I see are > AIX xlf90 : File cannot be opened the second time. > HPUX f90 : File cannot be opened the second time. > Lahey 95 : File is opened normally the second time. > DVF 6.0 : File is opened normally the second time. > Does the F90 standard leave this up to the compiler?
Metcalf and Giles (correctly) pointed out that the standard says that you are not allowed to open the file a second time. But one could draw an incorrect conclusion from that. For most questions about standard conformance, one must be pretty careful about whether one is talking about requirements on the compiler or requirements on the programmer. Most of the standard directly talks about requirements on the programmer. So... 1. Addressed to the user. As Metcalf and Giles pointed out, the standard says you may not do this. 2. Addressed to the compiler. But this isn't one of the kinds of things a compiler is required to diagnose. The compiler may, therefore do anything. The two "obvious" possibilities are the ones shown above, that it will give an error on the open or that it will just work. It is also plausible for the OPEN to work, but then have the files behave "strangely" (if, for example, the system ends up with two different, inconsistent internal records of file state). So to literally answer your question as stated: Yes, the standard leaves this up to the compiler. Which means that you as a user can't count on what will happen if you do this. And it means that you don't have a basis in the standard for claiming that any compiler reponse to this violates the standard. One can still lobby for certain compiler actions, but you don't get to claim that the other possibilities are non-standard. -- Richard Maine
|
Mon, 17 Feb 2003 22:56:32 GMT |
|
|
netne #6 / 19
|
Opening a file already open
Quote:
> So to literally answer your question as stated: Yes, the standard > leaves this up to the compiler. Which means that you as a user can't > count on what will happen if you do this. And it means that you don't > have a basis in the standard for claiming that any compiler reponse to > this violates the standard. One can still lobby for certain compiler > actions, but you don't get to claim that the other possibilities are > non-standard. > -- > Richard Maine
Well, standard says No to open same file for two logical streams simultaneously, M.Metcalf and J.Giles even did not find to say something additionally here. S.Lionel added words about extensions and sharing. That's all sounds clear. Your respond starts in unison but then your last sentence made me dain bramage... (or may be just added). Again, why standard does not just say strictly that this is OS/compiler/vendor/heck dependent ? ---------
|
Tue, 18 Feb 2003 20:31:54 GMT |
|
|
Dick Hendrickso #7 / 19
|
Opening a file already open
Quote:
> > So to literally answer your question as stated: Yes, the standard > > leaves this up to the compiler. Which means that you as a user can't > > count on what will happen if you do this. And it means that you don't > > have a basis in the standard for claiming that any compiler reponse to > > this violates the standard. One can still lobby for certain compiler > > actions, but you don't get to claim that the other possibilities are > > non-standard. > > -- > > Richard Maine
> Well, standard says No to open same file for two logical streams simultaneously, > M.Metcalf and J.Giles even did not find to say something additionally here. S.Lionel > added words about extensions and sharing. That's all sounds clear. > Your respond starts in unison but then your last sentence made me dain bramage... > (or may be just added). > Again, why standard does not just say strictly that this is OS/compiler/vendor/heck > dependent ?
Because the standard says that about everything! The standard mostly puts requirements on a "correct standard conforming program." It doesn't say much about what the compiler should do for a non-standard conforming program other than it must be able to diagnose certain syntax errors and that some statements (allocate, read, etc.) should raise an error under a small set of conditions. It really can't be more specific because that would prevent vendor extensions. So the general rule is "if you write your program in accordance with the standard, then the standard tells you how it should work. If you don't follow the rules, then the standard doesn't (can't) describe what will happen." Dick Hendrickson Quote: > ---------
|
Tue, 18 Feb 2003 20:52:12 GMT |
|
|
#8 / 19
|
Opening a file already open
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
|
James Gile #9 / 19
|
Opening a file already open
... Quote: >Again, why standard does not just say strictly that this is OS/compiler/vendor/heck >dependent ?
The usual answer is that the standard only says what a conforming processor does with conforming code. If your code doesn't conform to the standard, the usual chorus is that the processor can "do anything! Including start world war three." This exageration is made to emphasize that processors are allowed to extend the Fortran language with features that the standard doesn't have in any way the want. (Unfortunately, it's also often used as an excuse for the processor doing very {*filter*} things to your code when you make a trivial, but undetected error.)-: So, a compiler (or other type of processor - an interpreter, for example) may allow you to violate rules of the standard in order to let you use the specialized features of their hardware and/or operating system. Some compilers may do a good job of both providing and documenting such extentions, others may not do either well. -- J. Giles
|
Wed, 19 Feb 2003 01:45:58 GMT |
|
|
#10 / 19
|
Opening a file already open
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
|
netne #11 / 19
|
Opening a file already open
Quote:
> It really can't be more specific because that would prevent vendor extensions.
With one compiler I use that rule already prevented vendor from extension. That caused me to write every time a lot of warning code and diagnostics around this collision of simultaneous open attempts. I had a perception (which, decently, is not always reality) that in the case of file is 'readonly' allowing multiple unit access would be harmless.
|
Wed, 19 Feb 2003 06:32:06 GMT |
|
|
#12 / 19
|
Opening a file already open
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
|
netne #13 / 19
|
Opening a file already open
Thanks, In other words, in black & white, (....) = is non-standard, but if (....) called 'extension', then (....) = standard (or in gray scale, "you don't get to claim that the other possibilities are non-standard") Right? --------
|
Wed, 19 Feb 2003 06:49:37 GMT |
|
|
#14 / 19
|
Opening a file already open
|
Wed, 18 Jun 1902 08:00:00 GMT |
|
|
Richard Main #15 / 19
|
Opening a file already open
Quote:
> > It really can't be more specific because that would prevent > > vendor extensions. > With one compiler I use that rule already prevented vendor from extension.
I think we must be running into language (English rather than Fortran) problems here again. No, there is no rule in the standard that prohibits vendor extensions in this or most other matters. Of course, there is also no rule that forces a vendor to do an extension. If a feature were required, then it wouldn't be an extension any more. -- Richard Maine
|
Wed, 19 Feb 2003 06:46:04 GMT |
|
|