Jing Guo writes:
> Does TR 15581 requires or implies that an allocatable component of
> a variable of a derived type shall deallocate itself? I am asking
> because I could not find any deallocate() statement in this new
> ISO_VARYING_STRING module. Automatic deallocation would be the
> only explaination in my opinion.
Yes. That is a *MAJOR* distinction between allocatable components
and pointer ones. It is one of the reasons why allocatable
components are so much more appropriate for this application.
> In another word, how can one tell if a compiler is non-broken?
That's a pretty tall order. Compilers can be broken in many ways.
Plausble brokenness here might include
1. Allocation failures. The runtimes complain that something is
already allocated when you try to allocate it. However, in the
*LARGE* majority of the cases, a message like this indicates a
user error instead of a compiler error.
2. Memory leaks. How to detect memory leaks is well outside the
scope of Fortran. Do things that might create big leaks and look
for signs of excessive memory usage. How to look for signs of
that is very much an operating system question instead of a
Fortran one.
3. All kinds of other problems because a compiler bug in this area
could quite plausibly cause memory corruption, which in turn
can cause all kinds of other symptoms.
In general, I'd have to say that the most accurate answer to
"how can one tell if a compiler is non-broken?" is that if you
have to ask, it probably isn't something that you are going to be
able to do. It doesn't have a simple answer.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|