/CHECKMATE gives a compile-time error, /DEBUG does not

The following code snippet illustrates my immediate problem.

If I compile with /DEBUG, all the implicit pointers are NULLified when the program loads, as per design intent of line 3. So no need for the executable statements.

If I compile with /CHECKMATE, on the other hand, the compiler generates error 1188 - This pointer assignment would assign a pointer to the wrong kind of data, in respect of the second commented line. If I comment out the executable statements, the implicit pointers are NULLified anyway

The only reason the executable statements are there at all is that without them, in my real code, the implicit pointers are NOT NULLified when I compile with /CHECKMATE. So I put those lines in, and now I can't compile at all. Bit of a Catch 22 ... 😄

So I can't build my real code with /CHECKMATE to diagnose why it isn't working until I can figure out the answer to this sub-problem. Help, please!

<edit 1> On a hunch, I tried sticking the type definitions inside a separate module, but it didn't 'help'; I can comment out the executable lines and the pointers are still NULLified as they should be, whether I use /DEBUG or /CHECKMATE. </edit 1>

Andy

      program pointery
      type p_rgbtree
        type (rgbtree), pointer :: next => null ()
      end type p_rgbtree
      type rgbtree
        type (p_rgbtree) :: ubernode
        type (p_rgbtree) :: node (2)
      end type rgbtree
      type (rgbtree), target :: rgbinfo
      integer nod
      rgbinfo% ubernode% next => null ()
      do nod = 1, 2
         rgbinfo% node (nod)% next => null () ! error 1188 here
      end do
      end program pointery

Two positive things first:

1. My compiler behaves differently which suggests that I have already fixed a bug in this area (it does remind me of a recent fix).
2. I think that you need to use

NULLIFY(rgbinfo%node(nod)%next)

when nullifying at runtime.

This ought to give you a way out till the next release but also raises two related unfixed bugs...

1. There is a false comment about P_RGBTREE being declared but not used and
2. Why are there different error and comment reports for /check.

Thanks, Paul,

A compiler writer's work is never done 8)

Interesting comment about the use of the NULLIFY statement rather than the NULL () function. I had always thought that they were synonymous except for declaration purposes (where only the latter makes sense). That's certainly the inference I draw from the FTN95 help file (see below). On the other hand, I find here:

http://h21007.www2.hp.com/portal/download/files/unprot/Fortran/docs/lrm/lrm0301.htm#null_intrin

as follows:

9.3.110 NULL ([MOLD]) Description: Initializes a pointer as disassociated when it is declared. This is a new intrinsic procedure in Fortran 95.

which seems clearly to state that NULL () is designed specifically for declaration statements. Only the standard can arbitrate this one - but it seems maybe there is a need also to amend the FTN95 documentation and have a compile-time error for use of NULL () in executable statements?

Andy

Syntax FUNCTION NULL([MOLD])

Description If MOLD is present it is a pointer of any type and gives the type of the result. If MOLD is absent then the type of the result matches the target of the assignment.

Return value This function provides an alternative to using the standard intrinsic NULLIFY. This functional form can be included with a declaration.

Example REAL, POINTER :: X ⇒ NULL( )

Just to confirm that I have now tested the use of NULLIFY (...) rather than ... ⇒ NULL () in my real code. The former compiles correctly and the later does not.