Automatic allocation of an available file unit
Joe Krahn
http://j3-fortran.org/doc/year/06/06-138r2.txt
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.
That's just my 2 cents.
I have been strictly avoiding constant unit numbers for a long time,
using a function that returns a free UNIT, found by a simple INQUIRE
loop, which also returns the unit number in an optional argument, so you
can do an open statement like this:
open(unit=file_unit(data_unit), ...)
read(data_unit,...)
Joe
Richard Maine
> 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.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Paul Van Delst
Doesn't everyone do something like this? :o) Although I tend towards the:
fileid=get_lun()
open(fileid, ....)
read(fileid, ....)
method.
But, if you do the above doesn't it mean that you don't really care what the actual unit
value is? All you care is that it's valid to use for file I/O, right? So what does it
matter if it's negative? From the link you gave, if the NEWUNIT= specifier is used, you'd
do something like:
open(file='myfile.name',newunit=fileid, ....)
read(fileid, ....)
Same dog, different leg AFAICT.
cheers,
paulv
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
Pierre Asselin
> [ ... ] So I
> 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
a valid unit.
--
pa at panix dot com
Joe Krahn
> Joe Krahn <lastname_at_...@x.y.z> 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
Richard E Maine
Note that that assumption is already semi-broken by f2003. But I'll
admit that it is in a narrow enough case that the odds of old code
conflicting with it are negligable. It comes up in user-defined I/O. So
if your new (by definition) user-defined I/O procedure happens to invoke
procedures with old code, it could possibly come up. But that's just not
going to happen much.... if ever.
My own personal preference in this is to get out of using numbers for
this purpose at all. Of course, you'd have to phase them out over an
awfully long time (longer than any of us will ever see), but at least
one could fix the problem for new code. I was dissapointed to see that a
proposal to do that didn't "make the cut" at the last meeting. Seems to
me that any scheme to assign unit numbers is just a hack workaround.
Yes, it is what "everyone" (including me) does. I do agree that it is
better to standardize the workaround than to have everyone do their own
separate ones, which might not always work well together. And the
workaround is simpler to hack into old codes. But I'm still dissapointed
that the real fix got rejected.
The "real" fix is to have a non-numeric "handle". We already have the
basic mechanism for such "handles". It is a derived type with private
components; that perfectly matches the functionality of what is called a
"handle" in some other environments. The open statement would return the
handle, and the user would then just pass it around, without being able
to "muck" with its innards (well, not without "cheating", but we always
have that). All the I/O statements could take either a handle or a unit
number.
There was a proposal along that line.
I'm not sure why it didn't fly. Maybe a majority just thought it more
work than it was worth. (I'd disagree, but then I wasn't even there to
vote; doesn't look like one vote would have changed it anyway). Or maybe
it is just conservatism. For all the "newfangled" stuff that gets
proposed in some areas, I've personally noticed a reluctance in the
committee to use some of the features in the language itself. In
particular, using derived types for features of the standard doesn't
seem to go over very well, at least in my observation.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
Paul Van Delst
> Richard Maine wrote:
>
>> Joe Krahn <lastname_at_...@x.y.z> 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.
beli...@aol.com
<snip>
> But, if you do the above doesn't it mean that you don't really care what the actual unit
> value is? All you care is that it's valid to use for file I/O, right? So what does it
> matter if it's negative?
The NUMBER specifier for the INQUIRE statement returns the unit number
connected to the file, or -1 if there is no unit connected to the file.
Therefore I would never want -1 to be a valid unit number.
Paul Van Delst
From the original link, http://j3-fortran.org/doc/year/06/06-138r2.txt
<quote>
The unit number selected shall be negative, and /will not conflict/ with any positive unit
number, any negative unit number used for uddtio child unit number, /error codes
(INQUIRE)/ [emphasis mine], nor the * units.
</quote>
I didn't explicitly mention -ve error code exclusion in my post since the proposal text
already did.