Re: Automatic allocation of an available file unit

Joe Krahn wrote:
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'

One could take a different opinion of what a negative unit number means. In my case, I do the following,

fileid = get_lun()
if ( fileid < 0 ) then
...output error message that no valid fileid is available
...exit routine
end if

In that context, a negative unit number means an invalid/not-found unit number, not that a file couldn't be opened.

However, to use a -ve unit number to indicate an not-open file seems to be a me a case of using the unit number in a confusing manner, i.e. giving it more meaning than it should have. Checking for not-open files should be done via IOSTAT in open statments where the open failed, or via an INQUIRE(... OPENED=open_status) for those cases where the file is expected to be repeatedly opened and closed.

When the NEWUNIT specifier becomes available and I choose to use it, my code would basically eliminate the get_lun() call and subsquent check. Nothing else need change. I read something about this sort of thing recently in an OOP book - the word "decoupling" comes to mind.

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.

There shouldn't be any conflict. At least, I don't understand why there should be. The file unit finding routine (written by you) should determine if the unit is /valid/, not some magic number that changes from compiler to compiler (and may still be incorrect). I would assume that the NEWUNIT and IOSTAT specifiers in an OPEN statement would do the same for the prposed syntax.

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.

I almost, but not quite, emphatically disagree. Using unit numbers in Fortran95 to indicate *anything* about the the open status of a unit or file is /bad/ programming practice IMO.

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
.

Relevant Pages

  • Re: Automatic allocation of an available file unit
    ... 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. ... 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. ...
    (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)
  • Re: Use of C99 int types
    ... > Uhh, no. stdint.h is part of glibc, not the kernel. ... by the compiler and associated libs, ... ISO in order to avoid conflicts between user-code and the standard ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: What is the benefit of USE, ONLY(!)
    ... (snip of explanation of parsing using modules) ... clauses) are very specific. ... than the name in the module, even more useful in the case of conflicts. ... In one manual for the IBM Fortran H 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)