Newsgroups: comp.lang.fortran
From: Jos R Bergervoet <Jos.Bergervoet@philips.com>
Subject: This weeks question(s) about f2k
Date: Fri, 19 May 2000 12:56:19 GMT

Are derived types with allocatable components meant to be free of
memory leaks? My interest was raised because:

 1) One compiler (which supports them as extension) does not free
    the originally allocated memory of an intent(out) variable, and
    since such a variable acquires new allocated memory, it leaks.
 2) In technical report TR 15581 I cannot find the requirement that
    in the above case the memory should be freed.
 3) The f2k-draft, on the other hand, clearly states that it should:
    "When a procedure is invoked, a currently allocated ... subobject
    of an actual argument associated with an INTENT(OUT) allocatable
    dummy argument is deallocated." (Sect. 6.3.3.1, midway p107).

Since f2k seems to fix this potential leak (and also, like the TR,
seems to guarantee the leak-free behavior of function results and
assignments) I wonder if this completes the job. To be precise:

  Can I make a leak-free dynamic type by defining an "opaque" type
  with allocatable component(s)? Will the user of a library which
  defines such a type, be unable to create a leak, whatever s(he)
  does with this type?

I think the answer is yes, but do I overlook something? And is it
actually the intention of f2k to make this possible?


Since we're talking about page 107, we look 8 lines higher:

 "... a local variable of the procedure ... has allocation status
 as follows:
   (1) If it is accessed by use association, ..."

My question: how can something be a local variable of the procedure
and also be accessed by use association? Or, what does case 1 of the
second enumeration on p107 try to say?

We all know that it's difficult to stop when reading the standard :-)
Before we know it, we find ourselves in Sect.12.4.1.2, p257, reading

 "A dummy argument shall be type-compatible with the associated
  actual argument unless the dummy argument has INTENT(OUT) and
  is an allocatable or pointer. If the dummy argument is an
  allocatable or pointer that does not have INTENT(IN), the
  associated actual argument shall be type-compatible with the
  dummy argument."

Shouldn't the word "not" in the second sentence be left out? (Or
else, what does the text mean?)

-- Jos

-----------------------------------------------------------------------
  Dr. Jozef R. Bergervoet                      Electromagnetism and EMC
  Philips Research Laboratories,             Eindhoven, The Netherlands
  Building WS01                                     FAX: +31-40-2742224
  E-mail: Jos.Bergervoet@philips.com              Phone: +31-40-2742403

From: Richard Maine <maine@altair.dfrc.nasa.gov>
Newsgroups: comp.lang.fortran
Subject: Re: This weeks question(s) about f2k
Date: 19 May 2000 08:26:34 -0700

Jos R Bergervoet <Jos.Bergervoet@philips.com> writes:

>  "... a local variable...
>    (1) If it is accessed by use association, ..."
>
> My question: how can something be a local variable of the procedure
> and also be accessed by use association?

The term "local variable" as used in the standard doesn't mean quite
what you'd think.  It means something more like what I'd call "locally
accessible variable."  So if you want to talk about what I might call
a "really" local variable, you need to say "a local variable that is
not accessed via..." or something like that.

No, I don't particularly like the way these words are used in the standard,
in case it occurs to you to ask.  But that's the way it is.

One somewhat obscure issue that partly explains the strange wording:
In some cases where one talks about various forms of association,
there is a notion that the local variable is in some sense a separate
"thing" from what it is associated with.  This is certainly so for
variables in COMMON, less clear (at least to me) for USE and host
association.

I'll leave your other questions in the post to other people, at least
for now.  I don't have time to read that closely right now and the
answers don't pop off the top of my head.  (The answer that "yes,
allocatable components ought to be free of memory leaks" pops off the
top of my head, but checking that the text actually supports that is
harder).  Likley influenced by my brain fuzziness before getting my
morning coffee...and I've got time commitments afterwards.

--
Richard Maine
maine@altair.dfrc.nasa.gov

Newsgroups: comp.lang.fortran
From: Jos R Bergervoet <Jos.Bergervoet@philips.com>
Subject: Re: This weeks question(s) about f2k
Date: Mon, 22 May 2000 08:02:44 GMT

Peter S. Shenkin wrote:
>
> I guess my real question is, "Where does f2k guarantee automatic
> deallocation of allocated variables?"  F95, of course, guarantees
> this only for local variables without the SAVE attribute.

Most of it is in Sect. 6.3.3.1, p107 (Deallocation of allocatable
variables). Apart from the f95 mechanism you already mention,
this section adds automatic deallocation in more cases:
  * Function results are deallocated after they are used (that
    is, after execution of the statement with the function
    reference).
  * Intent(out) arguments of a routine are deallocated before
    the routine starts.
  * The above two rules also apply to sub-objects (allocatable
    components of a derived type).

There are other places where the topic comes up. For instance in
Sect. 7.5.1.5. p134. There we find the requirement that allocatable
objects (or sub-objects) are first deallocated before an assignment
to them is made.

> Is your question only about local variables (of derived type, with
> allocatable components) or is it about all variables of derived
> type with allocatable components?  If the latter, why should we
> expect automatic deallocation?

My question is about all these cases, since they can all lead to
memory leaks. I would expect that f2k has the intention to prevent
this, because otherwise I don't see much difference between pointers
and allocatables (yes, some, but not much).

On a more practical note: to make a "varying string" type or a
dynamic matrix type we simply need this leak-free behavior. In
current Fortran it is not possible (unless the user does the
cleaning up).

>                                -- unless, of course, the f2k
> proposal guarantees this for plain allocatables outside the local
> context.

f2k does not guarantee it in plain words, but it does take care of
all potential problems by the mechanisms described above. Only one
is unclear: the original f95 clean-up of locals should be extended
to allocatable components of locals. Page 107 only mentions an
"allocatable variable". But shouldn't we have something like:

 "On exit from a procedure containing allocatable variables or
  variables with allocatable components, all ... are automatically
  deallocated."

I think a similar text is in technical report TR 15581 (which is
about the allocatable mechanism) but in the f2k draft I can't find
it (I may have overlooked it).

-- Jos

From: Richard Maine <maine@altair.dfrc.nasa.gov>
Newsgroups: comp.lang.fortran
Subject: Re: This weeks question(s) about f2k
Date: 22 May 2000 07:24:39 -0700

Jos R Bergervoet <Jos.Bergervoet@philips.com> writes:

> I think a similar text is in technical report TR 15581 (which is
> about the allocatable mechanism) but in the f2k draft I can't find
> it (I may have overlooked it).

To busy to check right now.  Its certainly possible that someone
(maybe even me) overlooked transcribing that text from the TR to f2k,
but f2k is *supposed* to faithfully follow the TR.  It would have been
a point of some considerable controversy if f2k intetionally departed
from the TR on a matter of technical substance (which this would count
as).  I'm sure I'd have remembered the discussion that would no doubt
have caused.

--
Richard Maine
maine@altair.dfrc.nasa.gov

Newsgroups: comp.lang.fortran
From: Jos R Bergervoet <Jos.Bergervoet@philips.com>
Subject: Re: This weeks question(s) about f2k
Date: Mon, 22 May 2000 15:35:17 GMT

Richard Maine wrote:
>
> > about the allocatable mechanism) but in the f2k draft I can't find
> > it (I may have overlooked it).
>
> To busy to check right now.  Its certainly possible that someone
> (maybe even me) overlooked transcribing that text from the TR to f2k,
> but f2k is *supposed* to faithfully follow the TR.

No, it was me who overlooked it! It is on page 104, where we read:

" An allocatable object ... that is a local variable of a
  procedure or a subobject thereof, ... when the procedure
  is exited ... it is deallocated. "

In fact this section, 6.3.1.2, is partly describing the same as
Sect. 6.3.3.1, namely the effect that Return or End statements
will have on allocatable (sub-)objects. If your(?) J3 internal
note on p104 is correct, then it is once more repeated in Sect.
6.4.3.1, but probably that's a misprinted number.

This means that it probably is indeed the intention of f2k
to provide us with this method for leak-free dynamic memory
management, without requiring a garbage collector. I think
it's a very nice new feature of the language.

-- Jos

From: Jos Bergervoet <bergervo@iaehv.iae.nl>
Newsgroups: comp.lang.fortran
Subject: Re: This weeks question(s) about f2k
Date: 23 May 2000 20:57:17 GMT

Dick Hendrickson <dick.hendrickson@att.net> wrote:

>> to provide us with this method for leak-free dynamic memory
>> management, without requiring a garbage collector. I think
>> it's a very nice new feature of the language.

> Yes, I think that is the intent.  BUT, "automatic deallocation"
> does NOT mean that memory is returned to the "system" or to the
> "heap" or anything else.  It only means that the allocated function
> must return false.  It's a quality of implementation issue about
> how (or if) the memory gets reused.  F2k strongly encourages
> leak-free memory management, but doesn't require it.

I see! The standard only requires that we automatically get the
same as when the user would explicitely call deallocate. And that
is not required to real deallocating.

Nevertheless, it still means that on any system we have either:
  1) No deallocation is possible at all.
  2) It happens automatically for allocatable (sub)objects.
At least that means that the nasty situation of programming errors
causing memory leaks cannot happen. It could save a substantial
amount of work.

-- Jos