Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
27431 Discussions

Ifort accepts NULL() as argument to C_SIZEOF()

Harald1
Novice
285 Views

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
0 Kudos
1 Solution
Steve_Lionel
Black Belt Retired Employee
252 Views

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.

View solution in original post

4 Replies
Steve_Lionel
Black Belt Retired Employee
273 Views

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
Honored Contributor II
269 Views

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
Black Belt Retired Employee
274 Views

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
Black Belt Retired Employee
253 Views

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.

Reply