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