http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-08-17
18:29:28 UTC ---
(In reply to comment #1)
> a) I don't see what prevents a function from returning a short lived
> pointer
Nothing - except that it is bad if the pointer target is gone at the instance
of returning. Example:
function f () result (ptr)
integer, pointer :: ptr(:)
integer, allocatable, target :: a(:)
allocate(a(5))
ptr => a
a = [1,2,3,4,5]
end function
(There is some closed as INVALID PR which used such a code; the code above is
perfectly valid, one just may not dereference the returned function result.)
Here, "ptr" is a perfectly valid pointer within "f", however, "f" returns as
function result an "undefined" pointer. The program is perfectly valid, except,
one may not access the returned function result – which is a bit pointless. Of
course, the code works, if one reassociates "ptr" with some other target which
lives longer; still it is a bad programming style and asks for trouble.
That's the idea of the warning: Warn for questionable code.
Similarly for (c):
subroutine foo()
integer, pointer :: ptr(:)
...
call bar ()
...
contains
subroutine bar ()
integer, target :: tgt(5)
ptr => tgt
end subroutine bar
...
end subroutine foo
That's perfectly valid, but a dangerous way of programming. It becomes more
reliably if "tgt" has the SAVE attribute – but I believe that it is still
invalid to access "tgt" outside of "bar".
Note: I only talked about a local nonpointer target on the RHS for which one
should warn. For instance:
function foo(tgt)
integer, target :: tgt
integer, pointer :: foo
foo => tgt
end function
is perfectly valid and sensible if the actual argument is either a pointer or a
target. (It is also valid if the nonpointer actual argument has no target
attribute, but then the function result is an undefined pointer.) Hence, we
cannot warn for this case.
