(j3.2006) Interp 000068 and Fortran 2003

[Richard E Maine]

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  
> output
> 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  
this feature.

> 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  
below).

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  
conforming. And

   " 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