Consider the following snippet: implicit none integer, pointer :: p print *,associated(p) end This is actually invalid and should probably trigger a runtime error. Section 13.7.13 of the Fortran 2003 standard says that the pointer argument of ASSOCIATED should not be undefined, which it is in the case above (cf. section 16.4.2). Also see the discussion in http://gcc.gnu.org/ml/fortran/2006-06/msg00235.html and follow-ups. Right now the above program simply prints "T". This is kind of dangerous, since it looks like the pointer is associated with some target, while in fact it is not. ifort prints "F". I didn't check other compilers.
> This is actually invalid Yes, but this is a requirement to the program(mer) not to the compiler. > and should probably trigger a runtime error. Yes, but only with some checking option, otherwise it really gets too slow. Especially in the general case, you cannot easily check this. Setting by default "ptr = NULL" only hides the problem. * * * I think what you want is some -fcheck=pointer option (I think there is a PR about his). That option would initialize pointer with some bogus value, e.g. extern intptr_t _gfortran_bogus_pointer; integer *p, *bogus_local; bogus_local = &_gfortran_bogus_pointer; p = bogus_local { logical D14; if (p == &_gfortran_bogus_pointer) _gfortran_runtime_error("Bogus pointer at %C"); D14 = (p == NULL) print *, D14 } _gfortran_bogus_pointer is in libgfortran and the advantage is that one can also check called arguments, e.g. call foo(ptr) ... subroutine foo(ptr) if(associated(ptr)) ... Disadvantage is the speed, but that should not matter for a checking option. The checking has to be done before: - ASSOCIATED, DEALLOCATE - Actual arguments, which don't expect a pointer argument - Expressions which use the pointer (esp. "var = ptr"; is "ptr => uninit_ptr" valid?) - BUT: Not for allocate, NULL(uninitialized_pointer) or ptr => NULL(), nullify(ptr), ... I was once about to implement this, but especially if you want to get all cases right, it is a bigger patch. One could presumably start by initializing the pointer by "bogus_pointer" and add the checking before associate and deallocate, which should cover the most common problems.
The other bug is PR 29616.
I wonder if this should not be fixed ultimately by: (i) Allowing allocatable scalars, which should allow rank 0 descriptors to take the field; and (ii) Once we have array descriptors that flag the status of the data, include pointers in the club? Confirmed and marked as accepts-invalid. Paul
> (ii) Once we have array descriptors that flag the status of the data, include > pointers in the club? I prefer to have simple pointers for scalars and use the descriptor only for arrays/strings/dimension(..) for performance reasons; though one could use the descriptor with -fcheck=pointers.
Fixed on trunk. I will wait a few weeks before fixing on 5-branch. Paul
Sorry for the noise - I didn't mean to touch this one! Paul
(In reply to Tobias Burnus from comment #1) > I think what you want is some -fcheck=pointer option (I think there is a PR > about his). That option would initialize pointer with some bogus value, e.g. -fcheck=pointer is available since gfortran 4.5, but even with gfortran 8 it still does not complain about the use of an undefined pointer in comment 0.
(In reply to janus from comment #0) > Consider the following snippet: > > implicit none > integer, pointer :: p > print *,associated(p) > end > > [...] > Right now the above program simply prints "T". This is kind of dangerous, > since it looks like the pointer is associated with some target, while in > fact it is not. ifort prints "F". I didn't check other compilers. Note that the output of this program actually seems to depend on the optimization level: With -O0 I get 'T', but with -O{1,2,3} I see 'F.