[Bug libfortran/48587] Avoid exhausting unit number with NEWUNIT=

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48587

--- Comment #2 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-04-13 10:46:42 UTC ---
(In reply to comment #1)
> There is a problem with reusing numbers - it is probably only a small one - but
> it might be larger than the problem of running out of unit IDs:
> 
> The user might reuse NEWUNIT= IDs:
> 
> Open(newunit=id)
> ...
> close(id)
> open(unit=id) ...
> 
> The latter is illegal as one may only pass positive numbers to unit=, but I
> would not count on it.

I don't see how this would differ from the current behavior vs. my suggested
implementation. In any case, we check that the UNIT= number is positive when
opening units:

program negative_unit
  implicit none
  open(-10, file="foo.txt")
  write(-10, *) "Hello world"
  close(-10)
end program negative_unit

$ ./negative_unit 
At line 3 of file negative_unit.f90
Fortran runtime error: Bad unit number in OPEN statement

(this is with 4.4; presumably this restriction hasn't been lifted?)

Both the current implementation and my suggested one ensure that any unit
number returned in NEWUNIT= is negative. This ensures that the UNIT= and
NEWUNIT= number ranges are kept separate from each other, so they shouldn't
interact.

> Given that the number is huge, we decided that the
> current method of just incrementing the value should be sufficient for nearly
> all cases and one can think about something clever if a real-space code
> encounters the problem.

Ah, but what about a k-space code? ;)

> However, I don't mind if one solves the problem before.

Yeah, well, I don't think this is a big deal; after all it's pretty unlikely
that any program will overflow the counter.