(j3.2006) (SC22WG5.3702) [ukfortran] Ballot on the technical content of the TR
Tue Dec 2 23:38:36 EST 2008
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.
There is no reason to exclude the VALUE attribute, as the C argument is
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
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
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)
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.
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 184.108.40.206, 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
"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