(j3.2006) Question about lbound of an assumed-rank entity

[Cohen Malcolm]

Bill Long writes:
<<<
When calling a procedure with BIND(C) a Fortran caller does not know what 
language was used to write the callee. What it does know is that the BIND(C) 
callee uses the C calling conventions.  So the callee will get the address 
of a C descriptor as the incoming argument.  Even if it was written in 
Fortran.
>>>

It still has to produce the output required by the standard.  The standard 
says that the lower bound of the dummy is LBOUND of the actual; it does not 
say "unless the procedure being called has the BIND(C) attribute in which 
case the lower bound is zero".

Therefore, it must produce "2 2 2".  There is no doubt or ambiguity 
whatsoever.

This does mean that. as it is currently written, the "lower_bound" field of 
the C descriptor cannot be used as is for the lower bound in Fortran, since 
that specifies that field to be zero.

Or there is a mistake in the TS.  We can fix mistakes before publication (of 
the standard) if we can resolve them.

Speaking from a language design viewpoint, if assumed-rank is supposed to 
act like "assumed-bounds", it needs to do that always, not just on Tuesdays. 
There should be (and currently *is*) no case where the result of a 
conforming program without processor dependencies is changed simply by the 
addition or removal of BIND(C).

I take Reinhold's point about assumed-rank being "assumed-bounds" is a very 
dubious design point.  Fortran 90 added assumed-shape and not assumed-bounds 
for good reason, or rather, several good reasons.  One being that it is 
harder to write code to process assumed-bounds, and the code is a bit less 
readable than the code for assumed-shape.  Another being that there are many 
contexts in Fortran where one inescapably "loses" the bounds information, 
and having assumed-bounds would expose that in an unhelpful manner.

The technical problem with BIND(C) would probably be solved by making 
LBOUND(assumed-rank)==1.  It *might* be slightly more work than the compiler 
inconsistently blatting around C descriptors carelessly.  But the compiler 
should be required to do the work to make the results consistent and 
correct.  And if any extra work is required it is as nothing compared to the 
current state, which requires LBOUND in Fortran to give the bounds of the 
actual argument, and lower_bound[] in C to give zero.  One might think that 
this would be a change from the TS..., but...

Examining the TS more closely, this requirement (that "assumed-rank" acts 
like "assumed-bounds") is buried in the Edits section of the TS.  Indeed, 
the ordinary section of the TS (the one that mere mortals are supposed to 
read, and which is supposed to contain the full technical context) says
QUOTE:
   "If the actual argument has rank greater than zero, the rank and extents 
of the dummy argument are assumed from the actual argument, including the 
lack of a final extent in the case of an assumed-size array. If the actual 
argument is an array and the dummy argument is allocatable or a pointer, the 
bounds of the dummy argument are assumed from the actual argument."
ENDQUOTE:

This says that assumed-rank for the nonallocatable nonpointer case acts like 
"assumed-shape", NOT like "assumed-bounds".  (Let's not try weaselling that 
things unstated are true: at best they are not standardised, and therefore 
no interpretation is established, and therefore not conforming.)  Thus we 
have an internal contradiction in the TS: the edits section which states it 
"provide[s] the facilities described in foregoing clauses", introduces a new 
technical effect which is NOT described in the preceding clauses.

Therefore we can (and should) fix this with a clear conscience.

SUMMARY:
(1) The TS does not require LBOUND of assumed-rank to give the LBOUND of a 
nonallocatable nonpointer actual, because you cannot introduce a new 
technical effect by burying it in the edits section,
(2) Requiring LBOUND of assumed-rank to give the LBOUND of a nonallocatable 
nonpointer actual, as the 007 does now, would either create a lot of extra 
work for the processor (it cannot use lower_bound in the C descriptor for 
the lower bounds, but has to pass them around separately) or produce 
inconsistent results,
(3) Those problems go away if nonallocatable nonpointer assumed-rank acts 
like assumed-shape (LBOUND==1), and this is easy to implement.

Cheers,
-- 
.............Malcolm Cohen, NAG Oxford/Tokyo.