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.
