Re: Automatic allocation of an available file unit

Richard Maine wrote:
Joe Krahn <lastname_at_niehs.nih.gov@xxxxx> wrote:


I see that the plan is to use negative unit numbers for automatically
assigned units. It seems to me that there would be fewer conflicts by
using positive numbers starting at some number higher than the old compiler limits, an therefore unlikely to conflict with old code using
constant unit numbers.


What number is this that is higher than "the old compiler limits"? I
thought I recalled that some compilers allowed any postive number. On
the other hand, negative unit numbers have previously been invalid. So I
fail to see how numbers that were formerly valid could have fewer
conflicts than ones that were formerly invalid. I must have missed
something about your point.


The only bad part of allowing negative unit numbers is for people who use variables to hold file unit numbers, where an invalid value means the file is not opened. For example:
If (log_unit>=0) write(log_unit,*) 'log message'

As for what a "large enough" number is to avoid conflicts, I think something like 100 was a common limit, so one can assume that most portable code used numbers less than 100. This won't prevent conflicts, just avoid most of them.

It appears that either way, code with automatic unit allocation will have to be checked for conflicts, so it is more a matter of personal opinion. I would rather keep positive unit numbers instead of ending up with two distinct classes of unit numbers. My feeling is that any code that blindly uses a unit number without checking it is either primitive/old code or quick-and-dirty code, whereas using negative variables to indicate an unopened unit is 'good' programming practice.

Joe
.

Relevant Pages

  • Re: Automatic allocation of an available file unit
    ... It seems to me that there would be fewer conflicts by ... negative unit numbers have previously been invalid. ... The only bad part of allowing negative unit numbers is for people who use variables to hold file unit numbers, where an invalid value means the file is not opened. ... The file unit finding routine should determine if the unit is /valid/, not some magic number that changes from compiler to compiler. ...
    (comp.lang.fortran)
  • Re: Automatic allocation of an available file unit
    ... fail to see how numbers that were formerly valid could have fewer ... conflicts than ones that were formerly invalid. ... By old code assuming that negative numbers cannot refer to ...
    (comp.lang.fortran)
  • Re: Badness on the Warp
    ... Frans Pop wrote: ... invalid. ... You can have a "bum merge" where code conflicts logically, ... Intel Open Source Technology Center ...
    (Linux-Kernel)
  • Re: Automatic allocation of an available file unit
    ... assigned units. ... It seems to me that there would be fewer conflicts by ... What number is this that is higher than "the old compiler limits"? ... negative unit numbers have previously been invalid. ...
    (comp.lang.fortran)
  • Re: Automatic allocation of an available file unit
    ... I see that the plan is to use negative unit numbers for automatically assigned units. ... It seems to me that there would be fewer conflicts by using positive numbers starting at some number higher than the old compiler limits, an therefore unlikely to conflict with old code using constant unit numbers. ... All you care is that it's valid to use for file I/O, ...
    (comp.lang.fortran)