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



Tim Prince wrote:
Dylan Sung wrote:
I've noticed what seems to be a bug in the g77 compiler that comes with
Lepsh's Force 2.0 Editor and Compiler. If you open files using the unit
numbers 5 and 6, and then later close them, you cannot use 'print *' to
output messages to the screen dos console window. Later, altering those unit
numbers to 7 and 8 for the filenames I wanted to use, the print * ouput
worked again.

After some reading, it seems to me if I've understood it correctly, that
unit numbers 5 and 6 are used for screen or device driven input and output
in f77. Can anyone elaborate on this, and is this a general f77 thing or
specific to the build of g77 I have been using?

According to my understanding, in f77 and subsequent standards, unit=*
is required to be independent of positive numbered units in the
available contiguous range. Prior to f77, as unit=* was not generally
available, the substitution of pre-assigned units 5 and 6 was usual
practice (never codified as a standard). If you check the record of
c.l.f, you will see repeated expert advice not to use single digit
units, for just such reasons, regardless of the standard.
It may be tempting to use units 5 and 6 in the expectation that they
will be pre-assigned in this fashion, while allowing the program to
redirect at will. Such a practice would be less portable than using
unit=* and relying on the redirection supported by most operating systems.

It is convenient to have a subroutine that can write to a file or print
to the console, depending on what unit number is passed to it. It is
less convenient to wrap IF statements around all WRITE statements to
choose between unit=* and unit=some_number. If a code assumes that 6 is
the unit for standard output, a PARAMETER should be declared and used
for this, to make this assumption clear.

.



Relevant Pages

  • Re: Help With Strings
    ... It is not uncommon for the limit on the number of open files to be ... standard input, standard output, and standard error. ... The missing last descriptor ...
    (comp.lang.c)
  • Re: Pass by reference in Fortran77 standard?
    ... > I'm wondering if anyone knowledgable about the f77 standard can ... > confirm that it /didn't/ specify an argument passing mechanism (i.e. ...
    (comp.lang.fortran)
  • Re: assumed-length character variable
    ... x is an assumed-length character variable: see the f77 standard 6.2.2. ... that had even a hint of requiring dynamic allocation. ... assumed-length character variables had such a hint, ...
    (comp.lang.fortran)
  • Re: Fortran 77 alphabet character $
    ... The f77 ... standard doesn't allow it. ... nonstandard code. ... you could compile with f95 by changing ...
    (comp.lang.fortran)
  • Re: what dialect of fortran is this ?
    ... it is an extended DO loop. ... Alternate return was introduced in f77, ... I can confirm that the f77 standard included alternate returns but not the ... but I remember seeing the extended range DO. ...
    (comp.lang.fortran)