(j3.2006) (SC22WG5.4005) [ukfortran] NOT on Paper 09-238

[N.M. Maclaren]

On Jun 11 2009, Aleksandar Donev wrote:
>
>First I have to understand your intention. Can you please explain this
>and how it is not covered by "Its value shall be...the C address of an
>interoperable data entity"?
>
>"C_F_POINTER is ambiguous about whether a C pointer with an interoperable
>type that has a valid value (either null or not) that does not point to
>an object is acceptable."

As I said, paper 09-238 did NOT cover this aspect, so the following is
completely irrelevant to it.  But, as it's an important matter in its
own right, here goes.  People of a sensitive disposition should stop
reading now :-)

But, please, please, please, do not read this in association with
09-238.  They are independent of each other.



Let's start with "data entity", and ask whether it has to involve actual
storage.

    1.3.39 data entity
    data object, result of the evaluation of an expression, or the result
    of the execution of a function reference

    1.3.40 data object
    constant (4.1.3), variable (6), or subobject of a constant (2.4.3.1.3)

    1.3.141 variable
    data entity that can be defined and redefined during execution of a
    program

Well, I think that the answer is "no".  The result of NULL() isn't a
data entity, but an unallocated ALLOCATABLE variable and a zero-length
array are.  So let's look at "interoperable" in this context.

    15.3 Interoperability between Fortran and C entities
    15.3.1 General

    Subclause 15.3 defines the conditions under which a Fortran entity is
    interoperable. If a Fortran entity is interoperable, an equivalent
    entity could be defined by means of C and the Fortran entity would
    interoperate with the C entity. There does not have to be such an
    interoperating C entity.

    15.2.3.6 C_LOC (X)
    ...
    Argument.  X shall have either the POINTER or TARGET attribute. It
    shall not be a coindexed ob ject. It shall either be a variable with
    interoperable type and kind type parameters, or be a scalar,
    nonpolymorphic variable with no length type parameters.  If it is
    allocatable, it shall be allocated.  If it is a pointer, it shall be
    associated.

    15.3.6 Interoperability of array variables
    ...
    An explicit-shape or assumed-size array of rank r , with a shape of
    [...] is interoperable with a C array if its size is nonzero and ...

I can't find much else that is relevant.  The second says that Fortran
zero-length arrays are not interoperable, and that C_LOC cannot be used
to get the 'address' of an unallocated variable or unassociated pointer
target, but says nothing about C pointer values.



So let's move onto C.  I shall omit the references, as they would be
unhelpful to most people, but typed C pointer values can exist in at
least the following 'states' (let's ignore 'void *' for now):

    1) Pointing to an actual, defined data object
    2) With a defined null value (i.e. like NULL())
    3) Pointing to the end of an array - such pointer values are fully
valid, don't point to an object, but can be subscripted with (say) -1 to
point to an actual, defined data object
    4) Pointing to an incomplete array at the end of a structure or
union - very like (3), but subtly different
    5) Pointing to an incomplete external static array (don't ask) -
these would become a gibbering nightmare if Fortran allowed zero-length
arrays to be interoperable
    6) Pointing to an object that has gone out of scope - those are
undefined values of the normal form (i.e. using them is undefined
behaviour, but they have a defined, useful value as an array of unsigned
char)
    7) Genuinely undefined pointer values - very like (6), but subtly
different, and not useful
    8) Pointing to a freed, malloced object - such values are undefined
to a degree unusual in C (e.g. even printing the value as and array of
unsigned char is probably undefined behaviour)

Now, (5) is currently excluded, (7), (8) and arguably (6) can be said to
be excluded on consistency grounds.  (1) is clearly defined, but what
about (2), (3) and (4)?

Note that, in C terms, they are first-class pointer values, with a
defined type.  And huge numbers of decent quality C programs use them as
such.  So why shouldn't a Fortran pointer be set up to use them?

Because we Fortran experts know that it doesn't make sense, that's why.
An ordinary user MIGHT deduce that for (2) from the specification of
C_LOC (though that's not a good place to have the restriction), but (3)
and (4) are merely a different way of pointing to valid objects.  We
experts know that Fortran has no equivalent feature, so interoperability
is implausible.

But WHERE in the standard is that made clear?


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679