(j3.2006) (SC22WG5.3730) [ukfortran] Ballot on the technical content of the TR
Wed Dec 3 23:39:19 EST 2008
On Wednesday 03 December 2008 04:19, N.M. Maclaren wrote:
> Unless I have completely misunderstood what it is proposing, N1761 does
> not provide the C with enough information to handle arrays of derived
> types, let alone derived types containing ALLOCATABLE arrays or data
> type conversion.
Please specify exactly what "enough information" encompasses? Types
containing ALLOCATABLE arrays (or pointers, or any other thing that is
actually a descriptor inside the object) cannot be interoperable, and
are not covered by N1761 by design decision. As to data conversion, that
is beyond the Fortran standard. MPI does with its MPI_Datatype maps, and
the user will still have to make those for derived types to tell MPI how
to copy them among different machines or how to pack/unpack them or
whatever. All the TR draft provides is the sizeof the struct, because it
is the most useful and obvious thing. In many cases additional info will
be needed, and the programmer has to pass that by mechanisms outside of
> Fortran VALUE has nothing to do with the argument passing mechanism,
> except in the current C interface.
And except that it was added to Fortran in *support* of a C-like
argument passing mechanism commonly used and commonly implemented in
compiler extensions. Sure, someone (undoubtedly an academic) on WG5
decides it could be generalized and did it, but that has caused more
problems than it is worth.
> In particular, look at 22.214.171.124
> paragraph 4 for the extra semantics it defines, and why it is useful in
> pure Fortran.
It could be done in Fortran before and it can still be done, without a
new attribute. Declare a temp, do an assignment yourself. No big deal.
> Why do you WANT to exclude the combination, for arguments that are
> necessarily NOT passed by value as C views it?
Because for arguments that ARE passed by value as C views it, e.g., a
simple one-word integer, many processors use passing conventions which
is in direct conflict with what they do if VALUE is used. So, instead of
forcing most everyone to massage conventions and thus re-introduce
processor extensions/overheads, we simply eliminate a mostly useless
functionality and limit the scope to allow more implementation
flexibility without really giving up user needs (remember: I am a user).
> That should be done before it is circulated for comments on the details;
> at present, I cannot tell what it means so cannot comment on it.
Do a grep of the standard. Anywhere it says assumed-shape, except for
where it defined what assumed-shape means (fairly obvious places) and
things explicitly specified as "except in .... these cases" in the TR
(notably rules about rank matching), replace "assumed-shape" with
"assumed-shape or assumed-rank". You will get the drift. I agree these
details should be spelled out, but the vote here is on "technical
content", to give guidance. I don't think anyone suggested this is ready
> > "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.
> Not once they are allocated, surely?
But they do not become assumed-shape once they are allocated, so I don't
get your point at all.
> That is completely wrong, for many, many reasons. How many people on that
> group were experts in C89, C99 and a wide range of interface conventions
> that use C?
Enough people in the group are casual or common users of C89/C99, and
most are common users of Fortran. As such, they are the target group of
the TR---the headers/tools from the TR are to be used by application
programmers, not C99 experts.
I agree that macros can be used to make the use of flexible array
members almost painless. If we actually provide such macros and tell
users how to use it, maybe it will be OK. I still find it distasteful,
but maybe that is because I dislike most of C anyway...
> You can allocate the space in several ways , including malloc and C99
> variable length arguments.
It requires explicit memory management, leading to bugs. One cannot even
declare such a descriptor on the stack. It complicates the most common,
simple uses, just to allow flexibility for "future".
> And the dereferencing is simple.
But having an array member of fixed size is arguably *much* simpler.
"simple" is an absolute term and thus depends on who is making the
statement. The relative comparison, "simpler", is, I think, without
> And the REALLY strong argument against binding fixed sizes into the
> specification is that it prevents later extension. 50 years of
> experience is that this is almost always a mistake. What about a
> Fortran compiler that doesn't impose any hard restriction on the number
> of dimensions? Why should a vendor be penalised for NOT writing old
> fashioned code?
Because such an extension is outside the Fortran standard and that
vendor can provide, along with the extension, an extension of the TR.
Sorry, we don't support arbitrary-rank arrays, already.
> If you want a C89-compatible type to use for stack or static allocation,
> there are several ways that can be done cleanly (by C standards). Yes,
> they involve a cast. For example, by providing a macro:
> CFI_array_alloc(7) temp;
> CFI_array *ptr = (CFI_array *)temp;
Using stack space and type casts seems acceptable, at least to me, as a
user. If others agree, we can change the design to use flexible array
BTW, are most/all compilers know C99-compatible, an in particular, do
they support the features needed to make your proposal work? This was
one of the considerations, as I recall, against using flexible array
> > 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.
OK, good you agree, but I still don't know what your point was, i.e.,
what you actually want.
> That's not true. The Fortran compiler doesn't need to be told anything.
> All that is needed is that the thunking code knows what the two formats
> are. Been there; done that.
Does an existing Fortran compiler + C companion use thunking to pass
interoperable structs? Is one planning to? How do compilers today handle
changing the layout of structs on the C side?
> There are many such standard practices in C. Why not choose one of the
> ones that does not conflict with Fortran?
It was a judgement call among several people. You/WG5 majority/UK
delegation can disagree with it. I cannot make a technical argument
unless I do surveys of users.
> If you change the bounds without changing the stride, you will end up
> with an invalid descriptor. Doubtless you mean something different,
> but I have no idea what.
Yes, we mean that on input the strides are ignored, and the routine
calculates the correct strides and puts them in the descriptor, since
the array is contiguous it knows how to do that.
> Fortran passes an INOUT POINTER array argument to C. The C descriptor
> contains the base address of the target. C changes that address and
> calls CFI_update_fdesc and returns. Either that changes the pointer as
> Fortran sees it or it does not.
It changes what Fortran sees.
> If the former, then one statement is
> wrong; if the latter, the other is.
OK, now that we clarified, just tell us which statement is the problem
and we will fix it.
More information about the J3