Must nullify a pointer before check associated status in IVF.

[An_N_1]

hi,

I do known that pointers should be nullified by null() or nullify or associated to variable before checking associated status in deed.

Now I have a very large project in Lahey fortran, all pointers are not nullified before checking associated status, but it have worked well for decades of years. 

Now, I  need to transplant it to IVF for some reason, 99% of the upper situation brings no problem, associated function returns false as expected. But there surely is a very little case that  associated function returns true, which makes program crash. My question is: is there any laws, or i must change them all, but it will be a quite big job.....

Thanks!

[reinhold-bader · Accepted solution]

You will indeed need to change your program to assure that none of your pointers are in the "undefined" state when you invoke ASSOCIATED on them. The description of the intrinsic explicitly says so. An implementation may (as an extension) avoid this situation for the case that proper initialization is omitted, but you cannot rely on this being portable, and there are a lot of circumstances where pointers become undefined at run time. Note that IVF does support an option (spelt similar to "check pointers", but please read the docs) to do run-time diagnosis of illegal pointer accesses, which may help you to at least locate the problematic areas in your code.
 

Cheers

Reinhold

[An_N_1]

thank you reinhold-bader,

I tried "/check:pointer" option. And I also set "/check:bounds".

In the program, if a pointer is not associated, it will be allocated a block of memory as an array, or it will be regarded as an array which has been allocated.

On one PC, the program in IVF works well, on another PC, the associated function returns unexpected result, lead to use a uninitialized pointer as an array, because of "/check:bounds" option, a run time error of occured. If not "/check:bounds" it will work well too. But "/check:pointer" did not make any differences.

[mecej4]

The situation is not much different from using something such as "IF (K.EQ.0) THEN...ENDIF" without initializing K. Such a program is defective.  

That the defect surfaces only 1 percent of the time is of little comfort, unless you are able to live with a hand calculator that gives incorrect results of multiplication only 1 percent of the time, or a telephone that rings up numbers other than the one "dialed" 1 percent of the time.