Drew McCormack writes:

 > If you have another term that can convey to general programmers the
 > model used by Fortran, I'll be happy to use it.

I don't know of a good single term (other than "argument associated",
which isn't going to help anyone except the guru who has already
studied the standard in depth; it doesn't really describe the
ralationship - just gives a name to it). I just say that changing the
dummy argument also causes the actual argument to change. In my
experience, "general programmers" haven't even heard the term
"pass-by-reference" unless they have been "corrupted" by C, so you'll
have to explain what you mean anyway. (And programmers who picked up
the term from C are particularly likely to write buggy code if you
tell them that pass-by-reference is the model).

 > On a related issue, I seem to recall that in Fortran 90 the following
 > code was not guaranteed to work,...
   [code elided]

The only thing I see wrong with the code is irrelevant to your
question. Procedures with pointer dummy arguments need explicit
interfaces. I don't see one in your sample, but I really doubt that
is what you were talking about. Other than that, the code looks
perfectly fine to me (in f90 and everything afterwards).

Only two things that I can think you might be referring to

1. Things can get complicated if you point to a dummy argument.
    I don't even recall all the details of that. I'd not only have
    to look them up, I'd have to study very carefully and reread
    some interpretations on the subtle points. (And I'm not
    going to have time to do that). Other people on the list
    are probably more up on the question than I am. Yes, this
    gets into subtle issues of argument passing. But this
    is *NOT* what your sample code is doing.

2. If the target is an unsaved local variable, then you have
    problems. This isn't fundamentally any different from the
    issue of unaved local variables in f77 (and earlier, though
    things get murky prior to f77, where there wasn't a SAVE
    statement). Unsaved local variables become undefined when
    you exit a procedure. Has nothing to do with argument passing
    at all.

You might possibly be misreading the standard and thinking that
your code is a case of item 2 above. It isn't. If you are mistaking
it for item 2, then you are missing a fundamental thing about
pointers - a ponter and its target are 2 distinct things, even
if sometimes it seems unobvious. When you have a pointer B and do

  allocate(b)

that doesn't actually allocate B itself. (Yes, I know it reads
as though it does, but it doesn't.) What this does is 2 things.

1. The statement allocates an anonymous target. I call it anonymous
   because it doesn't have a name. It is *NOT* actually B; it is a
   separate thing all of it's own and has existance independent of B.
   This distinction is important.

2. The statement then makes B point to this target. There is now a
   relationship between B and the target (B is pointer associated
   with the target), but they are still separate things.

If you then do

  A -> B

this does *NOT* make A point to B. It makes A point to the target
of B. The difference is crucial. B is an unsaved local variable
and becomes undefined on exit from the subroutine. However, the
anonymous target is not a local variable and does not become
undefined. It maintains it's independent existance when the
subroutine returns.

 > In other words, it is valid to pass a pointer to a subroutine, and set
 > the pointer in the subroutine?

Yes. If it weren't allowed, then there wouldn't be much point
(so to speak) in pointer dummy arguments at all. There are certainly
particular thnigs you can do that are invalid, but nothing so
broad and fundamental as that.

--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
                             | -- Mark Twain