limit to number of files open??

[Intel_C_Intel]

Is there a limit to the max. no. of files that can be open at one time in Fortran 6.1, running on Windows 2000?

I have a problem where some apparently opened files are not being written to. I have 19 files open.

Thanks,
Ed

[Steven_L_Intel1]

No - there is no inherent limit.

Steve

[Intel_C_Intel]

I can vouch for that - I've had more than 100 files open before with no problems.

Tom

[Intel_C_Intel]

Thanks - I found the problem. The compiler was quite content to let me re-open the same unit number in the code and hence wiped any previous writes from the earlier open! Seems to me that the compiler should at least offer a warning for opening the same unit number without first closing it.

[Steven_L_Intel1]

Unfortunately, opening a unit that is already open, and thus silently closing the old file, is a feature of the Fortran standard, thus the compiler can't give you an error message. I hate this feature, but it is what it is.

Steve

[Intel_C_Intel]

But the compiler could certainly issue a warning message just as it does for floating point equality tests..........

[Jugoslav_Dujic]

...but it can't deduce it at compile-time - only at run-time. Or you'd want a "Warning: If this unit is already connected to a file, that file will be closed" on
each OPEN statement? ;-)

!-------------------
Just a test - ignore it - will this new stuff screw code?

SELECT CASE(Msg)
CASE(WM_INITDIALOG)
IF (m_iX.LT.0) THEN
iSt=GetWindowRect(GetParent(hDlg),Rect)
IF (IsWindow(m_hParent)) THEN
iSt=GetWindowRect(m_hParent,WinRect)
ELSE
iSt=GetWindowRect(GetDesktopWindow(),WinRect)
END IF
iSt=SetWindowPos(GetParent(hDlg),0, &
(WinRect%Right+WinRect%Left-Rect%Right+Rect%Left)/2, &
(WinRect%Bottom+WinRect%Top-Rect%Bottom+Rect%Top)/2, &
0,0,SWP_NOSIZE.OR.SWP_NOZORDER)

[Intel_C_Intel]

Jugoslav,

You are correct, which is why I would like to see CVF move towards building in a dynamic analysis of code during runtime as per some of my previous posts. Some coding problems can be found during comilation, but others can only be found during execution and these capabilities can and have been built into other compilers.

Tom

[Steven_L_Intel1]

A run-time warning for a behavior specified by the Fortran standard would be inappropriate. I don't see us doing this.

Steve

[Intel_C_Intel]

Steve,

A warning is just a warning that the programmer might be doing something that they may not have really intended to do, such as doing an equality comparison between floating points even though this is entirely permitted by the standard as are a number of other warning and info messages sent out by CVF. It seems to me that anything that compiler writers can do to help programmers produce "correct" code faster, as you like to put it, would be welcome.

If runtime warnings such as this were in the compiler, it would probablye have saved Ed enough time and money to have paid for the next compiler upgrade as I have a feeling he spent a number of hours tracking this down.

If FORTRAN compiler writers always adhered to the strict FORTRAN standards, we never would have had F90/F95 as it now exists as many of the new features were nonstandard FORTRAN to start out with but became so common and useful that they were adopted in the new standards - but it appears we are getting back into the philosophical realm of compiler development.......

Tom

[Jugoslav_Dujic]

In general I agree with you -- however, it seems that we're all stuck with that particular stuff. Note that it's virtually impossible for compiler to examine all posible branches in all possible source files where the file of particular unit may be open but not closed -- I really can't blame Compaq's people for not implementing that. However, it's that stupid standard rule that's preventing compiler (RTL, more precisely) to raise a run-time error -- if it does, the fix would be easy.

Let me take a parallel with ALLOCATABLE arrays: it's illegal to ALLOCATE an
already ALLOCATEd array -- but you'll get a run-time error if you try this (not
with POINTER arrays though). It's equally impossible (as file units problem) for
the compiler to keep track of it at compile time -- but the run-time error indicates
that the code is broken and the fix is relatively easy. All I can offer are my sympathies for Ed :-(. Personally I prefer solution as in C's fopen where RTL takes care of opened files and returns a handle (unit) instead of it being input argument as in Fortran -- but that's the heritage of the past. Remember, Fortran originates from 50's...

Jugoslav

[Intel_C_Intel]

Jugoslav,

Rules, aka standards are meant to be broken (my caveat - if it's for a very good reason).

Tom

[Jugoslav_Dujic]

Then, can we reach an agreement that we request a "Raise run-time error on opening already opened files" compiler switch? :-)

[Intel_C_Intel]

You betcha - anything to help code developers.

[Intel_C_Intel]

Following up on some of the prior correspondence, I spent about 1/2 a day resolving my user-introduced "bug." The problem was that I was merging together two rather large pieces of complex code, and the unit numbers slipped by me!

I tend to agree that anything that makes the software developer's job easier and faster, without cluttering the process up, is good.

Thanks for all the replies.

[Steven_L_Intel1]

Ok - I'll take it as a general suggestion that we add an option to do more compile-time and run-time checks of "questionnable" usage, optional of course

Steve