[comp.lang.fortran] Fortran 8x: implicit dereferencing

corbett@beatnix.UUCP (Bob Corbett) (06/27/89)

     I lost track of the reference, but I recall reading that someone thought
implicit dereferencing of pointers is one of the things X3J3 got right.  I
suspect that if implicit dereferencing remains in the language, it will be
the most often cursed feature of the language.  In a sample Fortran 8x
program, Walt Brainerd wrote

       TRAIL_PTR = TMP_PTR

where he meant

       TRAIL_PTR => TMP_PTR

I believe this error is exemplar of what will be a common form of error in
Fortran 8x.  Now consider when this error will be detected.  It will not be
caught by the compiler or the run-time system because it is legal code.
Furthermore, the error will not manifest itself until some time after it
has occurred.  This problem will generally be harder to track down than the
infamous `=' in place of `==' problem in C.

                                                  Yours very truly,
						  Bob Corbett
						  uunet!elxsi!corbett
						  ucbvax!sun!elxsi!corbett

hallidayd@yvax.byu.edu (06/30/89)

Actually, Bob (corbett@beatnix.UUCP), the problems you see with Fortran's
implicit dereferencing of pointers (message <2776@elxsi.UUCP>) will be no
more troublesome than the explicit dereferencing of pointers in C.  Many
are the times when people find their C code not doing what they want (or
bombing due to illegal memory references) due to a lack of the ``*''
operator, or an extra ``*'' (particularly in the case of dummy arguments).

The biggest problem that probably caused Walt to make his mistake was the
weight of experience with other computer languages that _do_ require
explicit dereferencing of pointers.  Hence my suggestion that we call them
something else in Fortran, since the aliasing model used in Fortran is
really quite simple and straight forward, once you leave behind your
preconceived notions of ``pointers''.  I caught the error without _ever_
having seen the proposal, just a few examples were sufficient to orient my
working model for this type of referencing scheme.  I see no reason why
this should not be the case with other programmers, once they leave behind
their old models.

corbett@beatnix.UUCP (Bob Corbett) (07/07/89)

In article <668hallidayd@yvax.byu.edu> hallidayd@yvax.byu.edu writes:
>Actually, Bob (corbett@beatnix.UUCP), the problems you see with Fortran's
>implicit dereferencing of pointers (message <2776@elxsi.UUCP>) will be no
>more troublesome than the explicit dereferencing of pointers in C.  Many
>are the times when people find their C code not doing what they want (or
>bombing due to illegal memory references) due to a lack of the ``*''
>operator, or an extra ``*'' (particularly in the case of dummy arguments).

     Please note that I did not say that Fortran 8x derefencing would cause
more trouble than explicit pointer dereferencing in C.  I said it would
cause more trouble than the `==' vs. `=' problem in C.  My point was that
implicit dereferencing makes errors that are routinely caught by compilers
for languages that use explicit dereferencing indetectable.

     Consider again the example given in my earlier posting.  The statements

			  TRAIL_PTR = TMP_PTR

and

			  TRAIL_PTR => TMP_PTR

are both perfectly legal in dpANS Fortran.  After executing either statement,
the value referenced by TRAIL_PTR and the value referenced by TMP_PTR will be
the same.  Therefore, execution will continue for some time after the error
has occurred with no sign anything has gone wrong.  Now, consider the
analogous C code.  I suppose someone might write

			  *TRAIL_PTR = *TMP_PTR;

where he or she meant to write

                          TRAIL_PTR = TMP_PTR;

but it doesn't seem all that likely.

     Most C compilers do a good job of catching missing or extra `*' operators.
In most cases where there is a missing or extra `*', the type of the resulting
subexpression is off by one level of indirection.  Most C compilers give errors
or at least warnings when there is a type mismatch.  Admittedly, there are
cases where the C language makes it impossible to catch such mismatches.
At least part of the reason for adding function prototypes was to reduce the
number of cases where such errors can occur.  I do not feel it necessary to
make Fortran 8x less safe than C.

					    Yours truly,
					    Bob Corbett
					    uunet!elxsi!corbett
					    ucbvax!sun!elxsi!corbett