Ifort accepts NULL() as argument to C_SIZEOF()

[Harald1]

This shouldn't happen:

program p
  use iso_c_binding
  implicit none
  integer(c_int),     pointer :: ip4
  integer(c_int64_t), pointer :: ip8
  print *, c_sizeof (c_null_ptr) ! valid
  print *, c_sizeof (null ())    ! invalid
  print *, c_sizeof (null (ip4)) ! invalid
  print *, c_sizeof (null (ip8)) ! invalid
end

ifort accepts this and prints:

                     8
                     4
                     4
                     8

[Steve_Lionel]

Interesting observation. The standard says that NULL(), without the optional MOLD=, and used as an actual argument, takes on the type, type parameters and rank of the corresponding dummy argument. But C_SIZEOF is weird in that it has none of those attributes, and therefore there's no way to say whether or not it is interoperable. Since the standard does not provide an interpretation, the call with NULL() as an argument is not conforming.  A compiler isn't required to diagnose this.

Then there is the requirement that the argument to C_SIZEOF be a "data entity". An associated pointer is certainly a data entity, a disassociated pointer is not. Again, a compiler isn't required to diagnose this.

That said, the compiler certainly could special-case the use of NULL() here, and I note that NAG Fortran vociferously (perhaps a but much so) complains. gfortran gets an internal compiler error.

I'm going to run this by Malcolm Cohen for his thoughts. At a minimum I think that C_SIZEOF should require that if the argument is a pointer or allocatable that it be associated/allocated (see LBOUND, for example.)

[FortranFan]

It is inconceivable the circumstances where the result of the NULL intrinsic per the current Fortran standard can be "an interoperable data entity."

[Steve_Lionel]

Thinking about this some more - the requirement that the argument to C_SIZEOF be interoperable completely rules out pointers, associated or not. So the compiler ought to complain here.

[Steve_Lionel · Accepted solution]

True, it is not, but getting there requires diving layers deep in the standard. However, there is a pending interpretation to the standard that would open up the possibility, as currently worded. Malcolm and I agree that this needs to be redone (it passed J3 but not yet balloted to WG5). Malcolm wants to prohibit ALLOCATABLE and POINTER altogether, but I think it is sufficient to require that the argument be allocated/associated with the same wording as used in LBOUND. He and I are discussing this further.