Re: closing unit=5 and unit=6 and print *


James Giles wrote:

I don't believe that subtle distinction is strong enough to allow what
DEC, Cray, and now Sun do. Suppose * and 6 (for example) are
two different identifiers for the same unit. Then closing the unit
idenitified by 6 should close the unit idenified by *, and that does
not happen for those implementations. I could weasel-word my
way around that, but if 6 is used to identify a unit in a subsequent
OPEN statement, it does not change the connection for * in those
implementations. I see no way to weasel-word my way around that.

Suppose that * and 6 (for example) were two different identifiers
for a different units both of which (by default) talk to an interactive
terminal. Since that's not a file, there's no violation of the rule
about two units connecting to the same file. So, closing 6 and
reopening it need not change the connection for *.

The Fortran standard has no concept of an interactive terminal.
External units are connected to files, not devices. Previous
versions of the standard did speak of devices with regard to
printing, but even that use has disappeared from the latest
standard.

Now, *if* redirection (say, on a command) were to associate both
identifiers with the same *file* this logic wouldn't apply. Is that what
happens? If so, I'd agree that they were in violation if the same
association between them were not preserved by CLOSE/OPEN
operations on one of them.

However, suppose that redirection changes the connection for *, but
not for 6 (which would still be connected to the terminal). I don't see
that to be a violation. That means that, by default, they are different
units connected to the same *device* (which isn't a file).

Again, there is nothing in the standard about connecting to devices.
In the logical model of I/O used in the standard, there are no devices.

So, if they both *always* stay connected together, I don't see
that as a violation. Or, if they never *change* together, but are
merely both connected to a non-file device by default I don't
see that as a violation.

If the external units identified by * and 6 are always treated as the
same unit or they are always treated as different units, there is no
problem. The DEC/Compaq/HP implementation (I don't know if the
behavior has carried over to Intel's implementation), Cray's
implementation, and Sun's implementation treat the units identified
by one of the uses of * and 6 as if they are the same unit initially,
but as different units if the unit identified by 6 is closed.

Bob Corbett

.

Relevant Pages

  • Re: closing unit=5 and unit=6 and print *
    ... I don't believe that subtle distinction is strong enough to allow what ... two different identifiers for the same unit. ... it does not change the connection for * in those ... there's no violation of the rule ...
    (comp.lang.fortran)
  • Re: Question about the clc string lib
    ... My reading of the standard says it is, ... >> I believe it is (and can't be asked to open the Standard right now). ... > Note first that macro names are identifiers. ...
    (comp.lang.c)
  • Re: AES trickery ;-)
    ... > the ISO version ... underscore and either an uppercase letter or another underscore are ... because it did not use such identifiers for ... the standard headers (hence part of the ...
    (sci.crypt)
  • Re: Variable Length
    ... Even when programming for C90, I only worry about identifiers longer than the older limit because they're a pain to type and make the code hard to read, not because I'm worried about their uniqueness on modern compilers. ... I'm very concerned about portability, but only in the forward sense; insofar as future versions of the standard remain backward compatible with the version of the C standard I'm currently writing for, I intend to write my code to be compatible with those future versions. ... I intend to make that true, no matter how much advantage they take of the things that are unspecified in the current standard in order to claim backward compatibility. ...
    (comp.lang.c)
  • Re: Do we need to continue to include stdio.h in C files ?
    ... no program can portably redefine any external ... Standard identifier, anyway; and if you ask me, no well-written program ... sometimes grows new identifiers it didn't possess before. ... I still have compilers for the previous Standard ready to use; ...
    (comp.lang.c)