(j3.2006) CFI_establish questions
Thu Oct 30 01:17:21 EDT 2014
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
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.
................................Malcolm Cohen, Nihon NAG, Tokyo.
More information about the J3