Re: Pointers to non-contiguous array slices

Richard Maine <nospam@xxxxxxxxxxxxx> wrote:
(snip on LOC(array section) not returning the address of the array)

Yep. That's exactly the source of the mistaken data I recall from
before. It is what you (well, I anyway) would expect from a LOC function
that was not specifically written with f90 array slices in mind and
integrated with the compiler.

Note in particular the "integrated with the compiler" part. It cannot be
done as an addon. Used to be that many things assumed Fortran data would
be passed by address. I've seen LOC functions for Fortran written in C.
In fact, that's pretty trivial to do if you assume that its argument
will be passed by address.

Well, there is also C_LOC for calling C routines that expect
a C pointer.

But I first knew LOC with VAX/VMS, along with the VAX defined
%VAL, %REF, and %DESCR to force a call by method for a specific
argument. First, many VMS system service routines expected pass
by value for some arguments. Also, you code store the LOC of something
in an integer variable and pass it using %VAL() to a routine expecting
a %REF argument.

But array slices are not passed by address. They can't be, as an address
is not sufficient information for a slice. You are usually going to see
one of two behaviors when array slices are passed.

VAX had %DESCR before Fortran had the need for descriptors.
Even more, the descriptor defined for it includes both the
address of the first element (needed for Fortran 90 assumed
shape) and the address of the virtual origin (element with
all subscripts zero) needed for PL/I. Assuming it is done
right, calls between Fortran assumed shape and PL/I should
work!

1. A descriptor is generated, and the address of that descriptor is
passed.

or

2. A contiguous copy is made and the address of that copy is passed.

For the descriptor thing to happen, the called procedure has to expect
such a descriptor and both the caller and callee have to agree about
this convention. That's likely to happen when you have an assumed-shape
(not assumed-size) dummy argument. It also requires an explicit
interface. Assumed-shape dummy arguments always require an explicit
interface and this is basically why - because the caller has to know
that a descriptor is expected; the explicit interface is how that
information is communicated.

-- glen
.

Relevant Pages

  • Re: null terminated strings
    ... descriptor, but the address of the first element of the array, and the array size needs to be defined in the subprogram? ... This meets all the behaviours required by the Fortran standard. ... are F90, and later, F95 standard compilers. ...
    (comp.os.vms)
  • Re: null terminated strings
    ... descriptor, but the address of the first element of the array, and the ... Fortran standard. ... F77 compiler. ...
    (comp.os.vms)
  • Re: null terminated strings
    ... I'm guessing that Fortran doesn't pass an array ... descriptor, but the address of the first element of the array, and the ... Whether or not the length of a passed array is also passed (as a ...
    (comp.os.vms)
  • Re: An array of arbitrary dimensions made from [0,1]?
    ... Fortran does not have arrays in which the subscripts ... In Fortran the rank of an array is fixed. ... the number of nested DO loops is fixed. ... descriptor. ...
    (comp.lang.fortran)
  • Re: Who uses clapack?
    ... > functions like SUM and MAXVAL and the ability to use array sections ... > drastically change the meaning of a Fortran code. ... >>Have you ever seen those bills for a Fortran compiler for an ... engineering applications in the C and C++ languages. ...
    (sci.math.num-analysis)