(j3.2006) Question about Comment GB20 on CFI_is_contiguous

[Malcolm Cohen]

Hi Bill,

>Comment GB20 asks to add "scalar or" to the Result value of  the 
>CFI_is_contiguous function.  However, the Description makes it clear that the 
>function is expecting a descriptor for an array. This was intentional since the 
>corresponding Fortran intrinsic, IS_CONTIGUOUS, requires an array argument, and 
>the Fortran concept of "contiguous" does not apply to scalars.  I would propose 
>alternate edits for this Comment:
>
>5.3.5.6, in the description of dv - Change "the object" to "an array".
>
>5.3.5.6, in the Result Value - Change "object" to "array".
>
>Is this an acceptable resolution for this Comment?

Maybe not quite.

The obvious options for fixing this are:

(a) Bill's suggestion, i.e. CFI_is_contiguous "requires an array", so if passed 
a scalar anything happens (CPU catches fire, program is terminated with an error 
message, whatever).

(b) U.K. suggestion, i.e. CFI_is_contiguous has a defined result if passed a 
scalar (we picked "true" since it seemed the most reasonable given we can only 
pick true or false).

(c) Specify that whatever is passed, CFI_is_contiguous returns a 0 or 1, but if 
the descriptor is not a valid descriptor for an array (but see comment in 
paragraph below), the result is processor-dependent.

(d) Change CFI_is_contiguous to return an error code and specify that it does 
return an error code for the scalar case.

Apart from the array-scalar case, I note that the description does not say what 
happens if passed a descriptor for an unallocated allocatable array or 
disassociated array pointer.  These are valid descriptors, even though they are 
not associated with an actual object in some sense.  There is also the invalid 
descriptor case; I don't offhand see where we address this issue (perhaps we are 
deliberately leaving it "not standardised"? or I didn't spot it in my 30 seconds 
of looking?).

Anyway, in other functions we specifically say that the descriptor shall not be 
for an unallocated allocatable or disassociated pointer; so that also seems like 
an oversight here.  I don't think this is deliberate, I just think that we 
copied the description from the intrinsic IS_CONTIGUOUS and forgot about all 
these problematic cases that are automatically excluded from the Fortran context 
but which can occur here.

Anyway, getting back to the options for fixing the function; I think we need to 
specify what happens (or that something is not allowed) in all the "valid 
descriptor" cases at least.  For the unallocated allocatable and disassociated 
pointer cases, I think it is reasonable to specify that they are not allowed.

Generally speaking if there is a "reasonable" answer, we should specify it so 
that we don't end up in the realms of undefined behaviour.  For the scalar case, 
the thing is that I can see this happening in normal use with assumed-rank 
dummies (and it is a common error to pass a scalar non-array-element actual to 
an array dummy).  For that reason I would tend to favour option (b) - the UK 
suggestion.

Clearly option (c) avoids undefined behaviour, but also prevents error 
detection.
Option (d) is probably too complicated for what is intended to be a simple 
function.

So my preference would be (b) then (a); I think (c) or (d) are both 
unacceptable.

In any case, I think the wording needs to be tightened up re 
unallocated/disassociated.  Simply disallowing these cases is I think the best 
option, especially since they are not allowed in the Fortran intrinsic.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.