First of all, sorry about the length of this post. I tried
to come up with a short piece of example code, but between the
code and problem description, it's still about 350+ lines.

I have been trying to improve my skills with regard to "f90"
syntax, but I've hit a snag. I'm fairly certain that I'm still
missing something with regard to understanding POINTERs, although
I've been programming long enough to realize that my problem
could be un-related and some silly mistake in some other section
of code.

What I'm trying to do is to create an array of a derived type
(refer to the sample code below for the actual implementation)

type (typ_surface),allocatable :: surf(:)
type (typ_surface),pointer :: surfptr

nsurf = 3
allocate(surf(nsurf))

where the derived types are declared as

Mark Stucky cox.net> wrote:

Likely. See below.

It isn't directly related tp your question, but the above strikes me as
oddly indirect and complicated. I'm not sure why you don't just directly
initialize surf(n) instead of allocating a temporary surfptr and then
copying its target to surf(n). That is just do

call alloc_surf(surf(n),ni,nj,status)

and, of course, get rid of the pointer attribute and the corresponding
allocation/deallocation in alloc_surf. Perhaps there is some reason that
didn't show through in my quick glance, or even was elided from the
posted code.

Anyway, on to the more central part.

Mark Stucky wrote:
...

...

I don't know if the update from V6.5 to V6.6 made in fixes that are in
areas that might have anything whatsoever to do with your problem; in
that regard I'd suggest fixing the problem Richard pointed out first
then go from there--if it is the only issue (and I read even less after
noting Richard had made his comment) you're on your way; if not either
you'll be able to see a problem yourself or can repost w/ a new issue.

But, the update to 6.6 is available at the HP Fortran site -- I don't
have a direct url, but a search thru the HP Fortran related stuff does
return it. Might be worth updating to at least the latest of what there
is. I'll note I'm also one stuck in the time warp of CVF but haven't
enough code which uses pointers that I still support to have any
experience as to what does or might not work w/ CVF. So, it's just a
general suggestion that may have no particular relevance...

--

Mark Stucky wrote:
(snip)

I am suspicious of the above statements (in two places).

Running with g95, it fails in the deallocate statement above.

Commenting out both of those, it runs and gives the desired
result. That is, both "correct" and "incorrect" output
are the same.

Deallocating memory that hasn't been allocated does very
strange things to the memory that is allocated.

-- glen

Mark Stucky wrote:
(snip)

I am suspicious of the above statements (in two places).

Running with g95, it fails in the deallocate statement above.

Commenting out both of those, it runs and gives the desired
result. That is, both "correct" and "incorrect" output
are the same.

Deallocating memory that hasn't been allocated does very
strange things to the memory that is allocated.

-- glen

Richard Maine wrote:

Rich Townsend wrote:
(snip)

(snip)

To expand even more, there is no need for the test at all.

With ALLOCATABLE variables, there is sometimes need to test
and deallocate before reallocating. That might sometimes be
true in the case of pointers, but not in this case. The program
wants to allocate a new pointer each time. There is no need
to check the pointer variable at all. No need to assign null()
to the pointer, and then check its allocation status in the
following statement. There is no rule against allocating using
a pointer variable that already happens to point to something.

glen herrmannsfeldt wrote:

dpb wrote:

...

for those who cannot easily find the cvf 6.5/6.6 updates, here are some
links that might be useful:
http://rapidshare.com/files/134110968/CVF-X86-65A.exe
http://rapidshare.com/files/134110961/CVF-65-66.exe <= 1
http://rapidshare.com/files/134110967/CVF-66A.exe
http://rapidshare.com/files/134110962/CVF-66-66B.exe
http://rapidshare.com/files/134110963/CVF-66-66C1.exe
http://rapidshare.com/files/134110965/CVF-66-66C2.exe
http://rapidshare.com/files/134110966/CVF-66-66C3.exe <= 2

Rich Townsend wrote:
(snip)

Well, you should copy the pointer somewhere else before
the new ALLOCATE. For the OPs problem, a new pointer should
be allocated each time, whether or not the variable happens to
be pointing to a previously allocated structure.

-- glen