------- Comment #1 from burnus at gcc dot gnu dot org  2009-02-18 17:28 -------
> 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.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39230

Reply via email to