From: Richard Maine on
LC's No-Spam Newsreading account <nospam(a)mi.iasf.cnr.it> wrote:

> Since a subroutine call passes the address,

That is not necessarly so and never has been. It is often the case, but
that has never been specified by the standard and there have been
exceptions, even in legacy compilers.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on
Richard Maine <nospam(a)see.signature> wrote:
> LC's No-Spam Newsreading account <nospam(a)mi.iasf.cnr.it> wrote:

>> Since a subroutine call passes the address,

> That is not necessarly so and never has been. It is often the case, but
> that has never been specified by the standard and there have been
> exceptions, even in legacy compilers.

Since it didn't say "call by reference," I had decided not to
comment on it. There is no other good explanation for assumed
size, especially in the case of passing an array element to
an array dummy. On the other hand, call be value result is
legal, with a copy made on one end or the other (or, I suppose,
both).

Some how, in some form, it has to pass the address of the
beginning of the array, or of the array element, to the
called routine. It could be indirectly, through a descriptor,
but a similar descriptor would have to work in all cases.
(You can pass an array element to either a scalar dummy or
array dummy.)

"Call by reference" has a pretty specific meaning, where
there is no specific meaning for "pass the address."

There are some interesting complications in C (which should
come through to Fortran's C interoperability) in that pointers
to different types may have different representations.
(Especially pointers to char on word addressed machines.)
C has specific requirements for conversion to/from (void *)
and (unsigned char *) that have to work, even in the case
of pointers with different representations.

The term "pass the address" is a little general, and it is
possible that "the address" of an INTEGER might not be
compatible with "the address" of a REAL.

-- glen