(j3.2006) CFI_establish questions

[Malcolm Cohen]

Bill Long writes.
<<<
This seems like a mistake. I agree that we should  say what happens in the case 
that the IF conditions of the initial sentence are not satisfied. The TS text 
says that elem_len is ignored unless?  The new last sentence should read 
?Otherwise, the value of elem_len is ignored.?   If you are setting up a 
descriptor for a CFI_type_int, for example, you do not want the user to think 
they can redefine the element length to 37 by supplying a bogus value for the 
elem_len argument.
>>>

I agree that it was my typo (I had to rewrite that sentence...).

If we need to describe anything about the action (on the descriptor) rather than 
the semantics of the arguments, that belongs in the Description paragraph, not 
in the Formal Parameters paragraph.  However I certainly don't want to add 
wording that partially duplicates what is said elsewhere, since that really 
leads to confusion.

It already says that the C descriptor becomes "an established C descriptor for a 
... data object ...etc.", and if we go back to 15.5.3 we can see that we have 
everything nailed down already:
  "The values of these members of a structure of type CFI cdesc t that is 
produced by the functions and macros specified in this part of ISO/IEC 1539, or 
received by a C function when invoked by a Fortran procedure, shall have the 
properties described in this subclause."
(and the value of the "elem_len" field is described in that subclause, and 
CFI_establish is one of those functions).

Steve Lionel writes:
<<<
if rank is non-zero but base_addr is zero, what, if anything, should 
CFI_establish do with the dim field of the descriptor? The text says that the 
extents argument is ignored in this case. I suppose it does no harm to leave 
these undefined, but it bothers me to do so.
>>>

The "extents" argument is ignored because a null pointer or unallocated 
allocatable has rank but no shape.  The user is not required to pass in an array 
of bogus values here.

As for the effect on the "dim" field, these certainly are intended to be 
"undefined". We don't want to require the processor to do work to fill in values 
that will be overwritten before they can legitimately be used; though it might 
be nice (especially in debug mode) to store some "impossible" values in there 
for diagnostic purposes.

I think 15.5.3's description of the "dim" field should explicitly say that its 
requirements on values does not apply to null pointers and unallocated 
allocatables though.  Sure we can work out that it's impossible to satisfy the 
requirements in this case and therefore they don't apply, but that's sloppy 
writing on our part.

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