Aleksandar Donev writes:
> I gather the scope of UNIT numbers is global per process,
The Fortran standard doesn't talk about processes. A UNIT number is
global to a program. Any issues of multiprocesing/multithreading
are outside of the scope of the Fortran standard.
> Can someone at
> least briefly explain to me why this system was made, instead of the
> OPEN or other statements explicitly returning a UNIT without the user
> having to enter one (like FILE pointers in C).
As with most questions about why some decision was made, I'm afraid
the answer is that, no, nobody can tell you why. :-(
For a case like this, that is particularly true. It was made sometime
in the 50's, well before even most of us old-timers were active in
Fortran. Anything I could come up with would be pure speculation.
My speculation, for what very little it is worth, would mostly center
on the idea that unit numbers of that era were often hard-wired to
hardware (like particular tape drives). Recall that before Fortran
77, there wasn't even an OPEN statement at all. Files were attached
particular unit numbers by means independent of Fortran - be that
hard-wired devices or job control cards.
And of course, there is now a big issue of compatability with existing
codes. As bad an idea as I personally think it is, an *AWFUL* lot
of existing codes use specific unit numbers hard-wired in the code.
Sometimes arithmetic is even done on unit numbers.
This is one area where I think the C way is better. But there is
an awful lot of inertia behind the old Fortran method. I'd like it
to be different, but its not at all clear that a real change is
likely to happen.
> Also, is there a way to write to something like /dev/null under
> UNIX (i.e. fake IO)? With scratch files the actual IO still happens--I
> want to ignore all WRITEs to a given UNIT.
No standard way within Fortran. YOu can, of course, open the
system-specific device /dev/null. You'll still probably get much of
the I/O overhead in the Fortran runtimes, but you'll avoid the
physical writes to disk. If you want to get rid of the overhead
also, I don't think you'll find any way other than putting tests
in the user code.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|