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

[Aleksandar Donev]

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

> 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 12.5.2.3
> 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 
for publishing.

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

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

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

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

Best,
Aleks