(j3.2006) Interp 000068 and Fortran 2003
Richard E Maine
Wed Jan 3 12:00:49 EST 2007
On Jan 2, 2007, at 2:02 PM, Michael Ingrassia wrote:
> Interp 000068...
> It says that the I/O unit identified by an asterisk for input or
> cannot correspond to more than one external unit.
> On the face of it, that implies an implementation that takes advantage
> of Fortran 2003's permission to use negative unit numbers for
> INPUT_UNIT and OUTPUT_UNIT would have to give up using units 5 and 6
> (respectively), because otherwise (say) stdin would be associated with
> both unit 5 and a unit with negative unit number.
Um... Did you actually read the fill text of the interp? It
explicitly addresses this. Namely, it says
Note however that a processor extension may have two units connected
to the same file - e.g. unit 6 and the * output unit might both
identify the user's display device. This is not detectable by a
standard-conforming program, but in this case closing unit 6 would
not necessarily affect output to the display device via *.
In particular, you probably forgot the important fundamental point
that the standard primarily defines standard-conforming programs.
Standard-conforming processors are indirectly defined in terms of
being able to process standard-conforming programs.
The interp does *NOT* say that a processor can't have two units
connected to the same file. In fact, the above quotation specifically
mentions such a thing as a possibly valid processor extension. The
interp just says that a standard-conforming program can't rely on
> Somehow, it doesn't seem likely (to this vendor) that users would
> let us
> stop using units 5 and 6 for stdin/stdout. Doesn't this make negative
> unit numbers completely unusable in practice ?
If I recall correctly (and I might not), the negative unit number
option was there mostly for vendors who do not currently use 5/6. I'm
not off-hand sure why a vendor who currently uses 5/6 would want to
add a negative number as an additional option. Perhaps there is a
reason, but I can't recall it. (Later. Oh yes, I recalled one. See
I think there was also some "funniness" about current implementations
where * was *NOT* the same thing as 6. Both displayed on the
terminal, but they were in some senses separate files such that, for
example, closing 6 did not affect output to *. Apparently some users
even expect that behavior. In fact, I distinctly recall objecting to
an earlier version of that interp, which amounted to trying to
retroactively trying to change the standard to specify the behaviors
expected by those users. I objected because some other users (such as
myself) did not expect that behavior. Since it was not an error or
other inconsistency in the standard, I thought it inappropriate to
make an incompatible change retroactively.
The business about disallowing multiple unit numbers connected to the
same file has been in the standard since f77. It is explicit and
clear and applies to all unit numbers. Yes, I think I recall both
compilers that didn't enforce it and programs that took advantage of
that lack of enforcement, treating it as a "feature" (even for files
other than stdin/stdout). The compilers weren't necessarily non-
standard. The programs were.
> Assuming that negative unit numbers as permitted by the standard were
> intended to be implemented, doesn't that mean that stdout (say) might
> be identified with more than one external unit? (Say, unit -3 and
> unit 6).
> Do we need an interp to say so?
> If so, should closing unit -3 affect unit 6 or vice versa ?
No we don't need an interp. I don't think we ever did, as the
existing language of the standard seemed explicit to me. Interp 68
was an attempt to retroactively change the standard. It wasn't
actually about an error or even lack of clarity in the standard. Some
people just didn't like what the standard clearly said. We certainly
don't need another interp on exactly the same thing.
As the existing interp says
"This is not detectable by a standard-conforming program.."
That is, if the program depends on this, it is not standard
" in this case closing unit 6 would not necessarily affect output
to the display device via *"
Not the "necessarily". That's pretty explicitly leaving it up to the
compiler... just like it always has been.
In fact, on thinking about it, that probably is a reason why some
vendors would want to use negative numbers as allowed in f2003. If
the existing implementation keeps * open when 6 is closed, the vendor
could use a negative number for * and have both that negative number
and 6 display on the terminal. As mentioned in the above interp, it
is then allowed for the vendor to choose the behavior where closing 6
doesn't close * (or the negative number which identifies the same
unit as *). Since INPUT_UNIT and * are different identifiers for the
same unit in f2003, the user is allowed to assume that closing (and
more interestingly, reopening) INPUT_UNIT also affects *. (With the
"usual" huge loophole that applies to all I/O.) That is, the f2003
standard forces the relationship between OUTPUT_UNIT and * that some
vendors now use and that some users (such as myself) find more
intuitive - they are different identifiers for the same unit. If you
want a different relationship than that between 6 and *, then make
OUTPUT_UNIT something other than 6 (possibly negative for minimal
interference), and you may.
The huge loophole mentioned above is the first para of 9.11 in f2003
(and similar words in other versions). A vendor can use that loophole
to "get by" with almost anything relating to I/O in a way that might
satisfy a lawyer (though it would make users pretty grumpy). In
particular, a vendor can claim that no units have the properties to
support any Fortran I/O at all and thus that any program doing what
looks like Fortran I/O is a non-standard program using a vendor
extension instead of standard Fortran I/O, where the vendor extension
just happens to look a lot like standard Fortran I/O with whatever
exceptions the vendor wants. I wouldn't try that argument on a
customer unless there was *REALLY* good reason for it (an embedded
system where there are no physical I/O devices might qualify as a
really good reason, but that's rare - though such beasts have existed).
Richard Maine | Good judgment comes from experience;
Richard.Maine at nasa.gov | experience comes from bad judgment.
| -- Mark Twain
More information about the J3