(j3.2006) (SC22WG5.3702) [ukfortran] Ballot on the technical content of the TR

Aleksandar Donev donev1
Tue Dec 2 23:38:36 EST 2008

Hi Nick,

Comments on your comments on the draft Interop TR. Sorry forthe 
confusing use of quotes---I use "---" to delimit the start of my 
response from your words.

"It also does not support the most important
required interoperability aspects (e.g. (a) below).
         a) the ability to call the MPI transfer functions with arrays
of interoperable derived types as choice arguments;"
Can you please provide an example of what it is you want to do. The TR 
is about calling Fortran routines with assumed-shape, allocatable or 
pointer dummies from C. Or are you talking about TYPE(*). Being specific 
will help understand the technical objection (as opposed to the general 
"I will write a proposal that does it better", which I look forward to).

"5) The UK's requirement against N1763 for MPI support also needs
support for non-blocking and one-sided transfers, it was answered by
being referred to this proposed Technical Report"
As you saw yourself, whoever answered you that way lied. There is 
nothing in the TR about asynchronous data transfers.

"Assumed-type variables
There is no reason to exclude the VALUE attribute, as the C argument is
a pointer."
Again, an example of what it is you want to see here would be useful. I 
have no idea what it would mean to have VALUE and pass-by-address at the 
same time.

"Assumed-rank variables
I do not know what the wording "In other respects, the rules for
assumed-rank dummy arguments are similar to those for assumed-shape
arrays" means, and whether it proposes any constraints on either the
processor or programmer."
Of course, it poses all the constraints that assumed-rank arguments do. 
These should be listed explicitly before this is made into a true TR 
document. Example:
If a pointer is associated to the dummy that is assumed-rank and has the 
TARGET attribute, and the actual has the TARGET attribute, the pointer 
becomes associated with the actual (the true words for this are more 
complex, of course)

'Is the
type "struct CFI_desc_t" (as "struct tm" in time.h) or "CFI_desc_t" (as
"div_t" in stdlib.h)?'
I believe the intention is that it be "struct CFI_desc_t" but I am not 
sure what the pros and cons are so it should be discussed.

"does not allow assumed-shape arrays to be allocatable or pointers"
Allocatable and pointer arrays are deferred shape---they are separate 
from assumed-shape arrays. So I don't undestand.

"Why should
assumed-shape but not assumed-rank be included together with associated
pointers and allocable variables?"
You mean you want a status value that says "this is an assumed-rank array"?

"It is completely unnecessary for "dim" to be specified of being a fixed
length.  C has the concept of a flexible array member as the last
element of a structure (C99, paragraph 16).  That would enable
all of the references to CFI_MAX_RANK to be removed."
Using flexible array members is horrendous. You have to malloc them, and 
then the de-referencing is obnoxious. Much much less user friendly than 
wasting a bit of memory and CFI_MAX_RANK. We discussed flexible array 
members in subgroup and decided against it. I stand by that decision.

'"ptrdiff_t" is a far better type for the purpose.'
OK, let's change that.

"The types need to include a non-interoperable type, for use with
assumed-type arguments.  The existing standard already allows them to be
passed between Fortran and C."
Does it??? How? One can pass a C_LOC of a non-interoperable entity, but 
it cannot be dereferenced in C, only passed back to Fortran.

"The layout of C structures is very dependent on the compiler options.
In the existing Fortran standard, the processor can (in theory, at
least) remap structures."
How is this different from BIND(C) types and whether they interoperate 
with the corresponding C struct? The "companion" processor has to be a 
good companion and not change layouts without the Fortran compiler 
knowing that.

"Because they are C interfaces, that is
plausible, but it is undesirable to use a specification that conflicts
with Fortran's conventions."
Well, either way, it will conflict with one convention (C standard 
practice or Fortran). We chose to please the C people since they are the 
most likely users of the interface.

"CFI_update_fdesc is specified to use malloc, but that is an 
unreasonable restriction on an implementation; the requirement should be 
This was only there so that free could be used without needing to 
specify a separate "deletion" routine. It should be re-considered.

'CFI_allocate says "The supplied bounds override any current dimension
information in the descriptors. The stride values are ignored and
assumed to be one. Both the Fortran and C descriptors are updated by
this function."  That makes no sense, as it would leave the descriptors
in an invalid state.'
I don't get it, please explain what you mean.

"The intent of CFI_bounds_to_cdesc is unclear, especially as it does not
say that creating an invalid descriptor is forbidden."
I don't want this routine to exist---I think it is useless. So is the 

"Fortran has no concept of the strides of the actual arguments being
visible to the called procedure."
But that is what we want to do here, obviously. Please suggest new wording.

'"The base address in the C descriptor for a data pointer may be 
modified by assignment and that change later affected in the corresponding
Fortran descriptor by the CFI_update_fdesc function" means that
allocatable and pointer arrays can be changed other than by calls to
CFI_allocate and CFI_deallocate'
Only pointers can be pointed by assigning the address. For allocatables 
one has to use the provided allocation/deallocation routines. This is 
because they may be automatically deallocated in the Fortran subroutine 
and the compiler will use its own allocator for that.


More information about the J3 mailing list