(j3.2006) CFI_establish questions

Lionel, Steve steve.lionel
Thu Oct 30 11:54:37 EDT 2014


Malcolm writes:
<<<
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).
>>>

I agree that the Description paragraph is where this should be, if we're going 
to say it.  But note that the end of the Description paragraph says "The 
remaining properties of the object are given by the other arguments." This is 
not true, as we seem to have agreed. The remaining properties can be derived 
from the other arguments. Would it be sufficient to say "given by or derived 
from" here?

Malcolm writes:
<<<
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.
>>>

Absolutely - I wasn't suggesting such a thing.

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

How about I write a paper for February suggesting some rewording? No technical 
change implied.

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6616 bytes
Desc: not available
Url : http://mailman.j3-fortran.org/pipermail/j3/attachments/20141030/9d38987c/attachment-0001.bin 



More information about the J3 mailing list