Re: language lawyer question

["Paul Thomas" <paulthomas2 at wanadoo dot fr>]

Paul

> Section 14.6.2.1.3 "Events that cause the association status of a pointer 
> to
> become undefined":
> "(3) Execution of a RETURN or END statement that causes a pointer's target 
> to
> become undefined."

Surely, this does not happen because the the target is in the scope of the 
main program and is pointed to through arguments?

> Section 14.7.6 "Events that cause variables to become undefined":
> "(3) The execution of a RETURN or END statement within a subprogram causes 
> all
> variables local to its scoping unit [...] to become undefined [...]"

The targets are not local to the function's scoping unit.

> None of the exceptions listed apply to the case above.

I agree and so do not understand how you conclude:

> Thus the return value of getOa (oa) has undefined pointer association 
> status
> after getOa has returned.
> A compiler might allocate ob on the stack, so it will be freed when getOa
> returns.

Does this mean that ob is being passed as a value?  I thought that fortran 
always passed a reference to the value?

> One way to avoid this is to mark ob as SAVEd

This conflicts with the dummy attribute and the compiler barfs on it.

In fact, the problem lies not in the function getOa but in the treatment of 
the temporary in the main program.  This works as intended:

program test
  use simpleObj
  use derivedObj
  implicit none
  type(objA),target :: oa
  type(objA),pointer :: oaptr   !add a pointer to an objA
  type(objB),target :: ob
  call new(oa,1)
  call new(ob,oa,2)
  call print(ob)
  oaptr=>getOa(ob)                 !assign the pointer function result to 
oaptr
  call print(oaptr)                    !instead of its being the argument 
of print
end program test

Best regards

Paul T