Passing Allocatable arrays into a subroutine which assumes their size

[Chris_H_3]

All;

Is it allowable to have a module with declared allocatable arrays used by the main program where they are allocated and then pass them to a subroutine where they have an assumed size?  It would look like this:

Program Main

Use Allocs

Allocate(x(npts))

Call Sub1(x)

End Program Main

where the Allocs module would be:

Module Allocs

Real,allocatable,dimension(:) :: x

End Module Allocs

and the sub would be:

Subroutine sub1(x)

Dimension x(*)

...so something with x inside its declared number of points range ...

End Subroutine sub1

[Steve_Lionel]

Yes, this is fine, Once the array is allocated, you can use it like any other array. 

[Chris_H_3]

Thank you, Sir!

[jimdempseyatthecove]

Chris,

Steve may have overlooked this (or I could be wrong on this)

Your subroutine sub is not inside the (optional) contains section of your module. As such, the program procedure has no interface for sub. While it will pass the base address of the array as a dummy, it knows not to pass the size.

Jim Dempsey

[mecej4]

As it will for any external subroutine with an implicit interface, the caller will only pass the base address of an assumed-size array argument. Likewise, the intrinsic SIZE is not allowed to be used in the external subroutine to to obtain the size along the last dimension of such an argument. Thus, given the following subroutine

subroutine sub(x,a,b)
implicit none
real x(*), a(2), b(3)
print *,size(x)
end subroutine

the compiler rejects it with the error message

sub.f90(4): error #6585: SIZE of array is not computable.   [SIZE]
print *,size(x)

Therefore, Chris H. should not run into any trouble on account of this issue.

[jimdempseyatthecove]

As the size of the assumed size array is not passed as a hidden argument...then, imho, "assumed-size" would be a misnomer. A more appropriate term would have been "indeterminable-size" or "unknown-size" or other synonym.

Where as a rank 1 "assumed-shape" assumes the size.

Steve, why did the standards committee choose these terms?

BTW, I find it humorous that the adjective assumed definition is: Used in a manner intended to deceive

As opposed to one of the verb definition of assume: To receive

Jim Dempsey

[Steve_Lionel]

Assumed-size has been in the standard since F77, some 30 years before I joined the committee. However, I think the term is appropriate in that the called procedure assumes it knows what the size of the passed array is. Before F77, programs would dimension array dummy arguments as (1) for this, since compilers at the time mostly didn't do bounds checking. I remember that VAX FORTRAN would treat (1) the same as (*), but DEC Fortran 90 did not, resulting in quite a few complaints from users.

If you want to quibble about terms, how about "adjustable arrays", where the bounds are expressions that can include other dummy arguments, COMMON or module variables?

I will agree that "assumed shape" seems a bit of an oddball here. Again, this term was created (for F90) well before I joined the committee - I keep catching myself mixing up assumed-shape and deferred-shape that have the same syntax but different semantics. I would probably have preferred "passed-shape" or something like that for assumed-shape, but they didn't ask me.

[jimdempseyatthecove]

Thanks, Steve. I wasn't trying to attribute the nomenclature to activities you personally had with the committee. Rather to solicit any information as to any internal discussion on the subject matter.

With interfaces and bound checking the choice of array(*).

I do have a gripe with the IVF documentation
 

The size of the array is assumed from the actual argument associated with the assumed-size dummy array as follows:

    If the actual argument is an array of type other than default character, the size of the dummy array is the size of the actual array.

    If the actual argument is an array element of type other than default character, the size of the dummy array is a + 1 - s, where s is the subscript order value and a is the size of the actual array.

This the size of the dummy argument is a functional property of the dummy argument. Seeing that the size is not determinable via size(x), ubound(x), print *,x, etc... while usable as array(index) erroneously with index out of bounds (not available to bounds checking), the description in the IVF reference guide (and lack of bad sample code), is less than adequate.

Jim Dempsey

[Steve_Lionel]

The issue here is that while the standard says what the extent of the dummy is, there is no mechanism specified to make that info available and the standard itself says you may not use SIZE(), etc., on an assumed-size array. It is up to the programmer to ensure that bounds are not exceeded. There do exist compilers that can pass extra, hidden info about the effective argument and can do checks against those, but this creates a compatibility issue with previously compiled code. Even then, these compilers do so only for error checking and you still can't inquire about the extents.