Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!apple!vsi1!altos86!elxsi!beatnix!corbett
From: corbett@beatnix.UUCP (Bob Corbett)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 8x:  implicit dereferencing
Message-ID: <2807@elxsi.UUCP>
Date: 7 Jul 89 02:09:30 GMT
References: <668hallidayd@yvax.byu.edu>
Sender: news@elxsi.UUCP
Reply-To: uunet!elxsi!corbett (Bob Corbett)
Organization: ELXSI, San Jose
Lines: 49

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