(j3.2006) Question about Comment GB20 on CFI_is_contiguous

[Malcolm Cohen]

-----Original Message----- 
From: Bill Long
Date: ?? 23?9?29? 13:02
To: fortran standards email list for J3
Subject: Re: (j3.2006) Question about Comment GB20 on CFI_is_contiguous

<<<
> 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.
>>>

Contrariwise, why do you want to go through the code that is set up to handle 
discontiguous chunks when there is a scalar?  All that extra work to handle 
discontiguous chunks is not only meaningless for a scalar but a pessimisation! 
The reason for asking about contiguity is not to "enable optimisation", it is to 
enable *the normal way C works* (see penultimate paragraph below).

<<<
I'm OK with requiring that the C descriptor actually describe an object,
>>>

As the existing text requires.

<<<
and making it a programmer error to supply a descriptor for an
unallocated allocatable or disassociated pointer.
>>>

Which matches the Fortran intrinsic, and arguably follows from the existing 
text, but is not clearly stated and thus interp fodder; it would be good to have 
a clear statement like we do for several of the other functions.

<<<
  I assume this comes
under C's undefined behavior, and the program can do what it wants.
>>>

Umm, that's "the *PROCESSOR* can do what it pleases"... but I'm sure that's what 
you meant.

<<<
Including returning 0, which is the useful choice anyway.
>>>

Since ".NOT.IS_CONTIGUOUS" implies that we have an object "with gaps", and thus 
we need special processing to handle the gaps, we clearly have different ideas 
of what the "useful" return value should be.  The normal C situation is that 
every object is contiguous, so it is the *discontiguous* state that is unusual, 
and also requires more work.

Since an array with one element is contiguous, it would be more than surprising 
to discover that both "is_contiguous(scalar)" is allowed and required to return 
FALSE!  I suppose having such a perverse definition might encourage programmers 
to check the rank first though... but if we are going that route, just don't 
allow "is_contiguous(scalar)".

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