(j3.2006) Interp 000068 and Fortran 2003

[Joanne Brixius]

The negative unit number was a result of an implementation
that used a table.  To hide the asterisk units, the implementation
started the units after -3, -2, -1 so that these could be used
for stdin, stdout, and stderr.  The user could then use the other
units as positive unit numbers.  The value of the unit for an
ASTERISK READ came through with a negative value to the libraries.

Joanne Brixius

On Wed, 3 Jan 2007, Richard E Maine wrote:

> 
> 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
> 
> _______________________________________________
> J3 mailing list
> J3 at j3.scs.gmu.edu
> http://j3.scs.gmu.edu/mailman/listinfo/j3
>