(j3.2006) Question about Comment GB20 on CFI_is_contiguous

[Bill Long]

On 9/28/11 7:06 PM, Malcolm Cohen wrote:
>
>> I'm beginning to think that the original wording was not that far off.
>> Here is a possible modification that might address the issues raised:
>
> No, this is going backwards.
>
> Forget the wording, what are you trying to achieve?  It looks like (c), which
> disagrees with my emails, with the UK comment, with your own previous email on
> what direction it was supposed to be taking, and with the rationale that it is
> just there to provide Fortran functionality to the C programmer.
>
>> Since the result value includes an "otherwise" option, there should be
> no uncovered cases.  If the descriptor is for an unallocated allocatable
> or a disassociated pointer, the "describes an array object" fails, and
> the "otherwise" specifies the result as 0. Similarly, if the descriptor
> is for a scalar, "otherwise" wins.  If the intent is to use this result
> to employ some optimized code for the case of the result = 1, then these
> result values give you what you need.
>
> This is completely unacceptable, and *NOT* what the programmer needs at all.

I don't understand.  This is exactly what I, as a programmer, would 
want.  What do you want that is different?

>
> Should the programmer be asking about a scalar descriptor (because of
> assumed-rank), then for the scalar case he DEFINITELY DOES NOT WANT to use the
> "unoptimised" code seeing as how the object is not discontiguous.
>

The concept of "contiguous" is meaningless for a scalar.  Why would you 
  want to go through the optimized code?   The optimization is likely 
meaningless for a scalar.

> Should the programmer be asking about an object that does not exist, that is a
> CLEAR ERROR and should not be allowed.

I'm OK with requiring that the C descriptor actually describe an object, 
and making it a programmer error to supply a descriptor for an 
unallocated allocatable or disassociated pointer.  I assume this comes 
under C's undefined behavior, and the program can do what it wants. 
Including returning 0, which is the useful choice anyway.

Cheers,
Bill


>
> Cheers,

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101