Prev: Passing optional parameters
Next: Renaming module procedures
From: Ron Shepard on 23 Sep 2009 01:41
In article
<78a1e9f3-16ee-40cc-9dd2-723318a59876(a)f18g2000prf.googlegroups.com>,
jfh <john.harper(a)vuw.ac.nz> wrote:

> program main
> call findxc(666)
> end program main
>
> subroutine findx (x)
> implicit none
> double precision x
> integer n,ientry
> ientry = 1
> print *,'findx entered at top; x =',x
> go to 10
> entry findxc(n)
> print *,'findx entered at findxc; n =',n
> ientry = 2
> print *,'ientry =',ientry
> x = 1.0d0
> print *,'x =',x
> 10 return
> end subroutine findx

The problem is that x is a dummy argument that is not associated
with an actual argument when the entry point findxc() has been
called. In this case, when findx() is called, then the dummy
argument n cannot be referenced, and when findxc() has been called
then the dummy argument x cannot be referenced.

$.02 -Ron Shepard
From: robin on 23 Sep 2009 19:14
jfh wrote in message <78a1e9f3-16ee-40cc-9dd2-723318a59876(a)f18g2000prf.googlegroups.com>...
>The following program causes a segmentation fault after the first
>print with every compiler I tried. I presume it is not standard-
>conforming but I don't understand why. I thought an ENTRY statement
>was allowed to specify a dummy variable of type a different from the
>one in the SUBROUTINE statement.
>
> program main
> call findxc(666)
> end program main
>
> subroutine findx (x)
> implicit none
> double precision x
> integer n,ientry
> ientry = 1
> print *,'findx entered at top; x =',x
> go to 10
> entry findxc(n)
> print *,'findx entered at findxc; n =',n
> ientry = 2
> print *,'ientry =',ientry
> x = 1.0d0

This statement is bad.
x is nothing at this point.
You cannot use it because it is a dummy argument
that does not have an associated actual argument.


Consider what happens when you make an assignment to
any dummy argument. The change is made to the actual argument, right?

Well, in this case, there is no corresponding actual argument!

That value is going to be stored somewhere. Where do you think?

> print *,'x =',x
> 10 return
> end subroutine findx
>
>Output with g95 (other compilers give similar results):
>
> findx entered at findxc; n = 666
> ientry = 2
>Segmentation fault


From: David Weatherall on 26 Sep 2009 02:37
jfh wrote:

> The following program causes a segmentation fault after the first
> print with every compiler I tried. I presume it is not standard-
> conforming but I don't understand why. I thought an ENTRY statement
> was allowed to specify a dummy variable of type a different from the
> one in the SUBROUTINE statement.
>
> program main
> call findxc(666)
> end program main
>
> subroutine findx (x)
> implicit none
> double precision x
> integer n,ientry
> ientry = 1
> print *,'findx entered at top; x =',x
> go to 10
> entry findxc(n)
> print *,'findx entered at findxc; n =',n
> ientry = 2
> print *,'ientry =',ientry
> x = 1.0d0
> print *,'x =',x
> 10 return
> end subroutine findx
>
> Output with g95 (other compilers give similar results):
>
> findx entered at findxc; n = 666
> ientry = 2
> Segmentation fault
>
> -- John Harper

My guess, particularly if this were VMS, would be that

call findxc(666)

causes the location that contains 666 to be in read-only memory.

x = 1.0d0

would be attempt to write to this location....

As it happens I came across a similar problem just the other day.

Cheers - Dave.

--

From: Richard Maine on 26 Sep 2009 11:21
David Weatherall <nospam(a)nowheren.no.how> wrote:

> > program main
> > call findxc(666)
> > end program main
> >
> > subroutine findx (x)
> > implicit none
> > double precision x
> > integer n,ientry
> > ientry = 1
> > print *,'findx entered at top; x =',x
> > go to 10
> > entry findxc(n)
> > print *,'findx entered at findxc; n =',n
> > ientry = 2
> > print *,'ientry =',ientry
> > x = 1.0d0
> > print *,'x =',x
> > 10 return
> > end subroutine findx
>
> My guess, particularly if this were VMS, would be that
>
> call findxc(666)
>
> causes the location that contains 666 to be in read-only memory.
>
> x = 1.0d0
>
> would be attempt to write to this location....

No it would not. be an attempt to write to that location. You are making
the mistake I referred to when I said

>>> The only thing I can think is that perhaps you are under the
>>> impression that this is an obscure way to equivalence x and n. It
>>> isn't.

x and n are *DIFFERENT* variables. There is absolutely nothing that
makes them be the same location. No, having the same position in the
argument list of two different entries does not do anything at all like
that.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: David Weatherall on 4 Oct 2009 03:28
Richard Maine wrote:

> David Weatherall <nospam(a)nowheren.no.how> wrote:
>
> > > program main
> > > call findxc(666)
> > > end program main
> > >
> > > subroutine findx (x)
> > > implicit none
> > > double precision x
> > > integer n,ientry
> > > ientry = 1
> > > print *,'findx entered at top; x =',x
> > > go to 10
> > > entry findxc(n)
> > > print *,'findx entered at findxc; n =',n
> > > ientry = 2
> > > print *,'ientry =',ientry
> > > x = 1.0d0
> > > print *,'x =',x
> > > 10 return
> > > end subroutine findx
> >
> > My guess, particularly if this were VMS, would be that
> >
> > call findxc(666)
> >
> > causes the location that contains 666 to be in read-only memory.
> >
> > x = 1.0d0
> >
> > would be attempt to write to this location....
>
> No it would not. be an attempt to write to that location. You are
> making the mistake I referred to when I said
>
> >>> The only thing I can think is that perhaps you are under the
> >>> impression that this is an obscure way to equivalence x and n. It
> >>> isn't.
>
> x and n are DIFFERENT variables. There is absolutely nothing that
> makes them be the same location. No, having the same position in the
> argument list of two different entries does not do anything at all
> like that.

Hi Richard
I've been away in UK for a week so apologies for the late
reply.

I see your point, and I know you know more about Fortran than I ever
will, but isn't it the case that x and n are different TYPE
definitions. They describe the types of the arguments passed into the
subroutine at its two different entry points. Where they are in memory,
if at all, is a function of the compiler, where they are declared in
the calling program and how they are used when calling the
subroutine(s).

That I'd accepted that x and n _would_ be the same location was
premised on my knowledge of some calling conventions and particularly
how the RSX-11M and VAX/VMS compilers do it. Some compilers may do it
differently and have some checks that could cause a warning to be
issued. That doesn't seem to be the case with the original poster's
compiler though.

Actually the point I was, unsuccessfully, trying to make was that the
argument passed to subroutine findxc (n) is likely, and certainly is on
VMS, to be in Read-Only memory. Any attempt to write to that location,
on VMS at least, will cause a memory protection/segment fault.

The other point that struck me later was that if n were 4 bytes then x
would be 8 and IF n and x were the same location then it would also be
possible to for n to writeable but adjacent to read-only code. In all
cases, I agree 'it is not good practise'.

As I said in the original, I had just found this self-same problem in a
piece of code I'd inherited and was modifying to meet a change in
requirement.

Cheer - Dave.

--

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Passing optional parameters
Next: Renaming module procedures