--On Monday, June 7, 2004 4:01 PM +0200 Drew McCormack
<[log in to unmask]> wrote:
> We have a compiler that is causing trouble when a pointer to an array
> is passed to a f77-like implicit function. It seems it is probably just
> passing the memory address of the pointer object, rather than doing a
> copy-in/copy-out, or something like that.
I'll repeat one of my most common statements about requests for debugging
help - I need data, not conclusions. I can't really comment on the above,
as it pretty much has no data - just conclusions, with no way for me to
verify them.
> Just to make sure I am not misinterpreting things, is this legal?
>
>
> real :: vertices(3, 3)
> real :: area, calcArea
> ...
> area = calcArea( array(1:2, :) )
>
> ...
>
> ! In another file, with an implicit interface
> real function calcArea( a )
> real :: a(2, 3)
> ...
> end function
I see nothing wrong with the above code. I also see no pointers in it,
which leads me to be even more dubious of drawing any conclusions based
on the first para. Do you actually mean pointers or something else that
you'd expect to be implemented sort of like pointers? Well, that's just
a rhetorical question that I don't really expect an answer to; just
trying to illustrate how little the first para tells me.
By the way, the standard doesn't require copy-in/copy-out; it is just that
that's by far the simplest way to implement some things. When I read the
first para, my initial thought was that you expected copy-in/copy-out to
happen and had code that depended on that, perhaps even for contiguous
actual arguments, where many compilers optimize the copies away. But the
code sample has a noncontiguous actual, so perhaps that wasn't the issue.
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
