🚀 go-pugleaf

In article <5919@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes:
>In article <5200048@m.cs.uiuc.edu> robison@m.cs.uiuc.edu writes:
>>Can anyone clue me as to the basis for pointer paranoia?
...
>Let's do some pointer arithmetic.
>First we need some declarations:
>
>	typedef struct {
>		int i;		/* say 4 bytes */
>		char c;
>	    } Node, *Nodes;
>
>	Nodes x, y;
>	int i, j;
>
>And then some code (assume with me that things are initialized):
>
>	x = y + i;
>
>This means assign the sum of y and i*5.  Not too bad, 1 shift and 3 adds.

What's so bad about that?  It is exactly equivalent to:

	x = &(y[i]);

In fact, except for the lack of structures, you do this in "Good Ol'
Fortran" (Look Ma -- No Pointers!) when you write code like:

	CALL POINTER( Y(I) )

	SUBROUTINE POINTER(X)
	... operations on X or even on X(J) ...

Why is this Ok when it happens at a grungy Fortran subprogram interface and
despicable when it happens within a nice clean C assignment syntax?  Pointer
arithmetic makes as much sense as array subscripting, because that's exactly
what it is...  except pointers are specified in a more self-consistent way
and, unfortunately, *EVERYBODY* is taught array subscripting first.

>Let's do some more:
>
>	j = x - y;
>
>Hmmm.  A subtract and a DIVISION by 5!?

True, but so what?  If x and y are pointers to objects within the same array
(as C requires) I find it perfectly natural to get the number of objects
between them as the result of subtraction.  If you don't like it, then don't
use it -- few people ever do...  after all, you can't do this using Fortran's
array syntax... so I guess it is expendable.  ;-)

>This stuff is great!  Plus costs 4 times what it should and minus
>becomes worse than division.  *And* it makes my code obscure to
>myself and others, not to mention hard to optimize.  Such a deal.

If, using your compiler techniques, pointer arithmetic is harder to analyze
than "Good Ol' Fortran" array references, then you are not doing very good
analysis of Fortran.  The only aspects in which C pointers are harder to
analyze than Fortran array references are:

[1] C pointers can be multi-level, i.e., pointers-to-pointers.
[2] C supports recursion, hence pointers/subscript expressions can be
    more difficult to decipher.

I think we can agree that [2] is desirable despite this.  IMHO, [1] wouldn't
be needed if C would allow first-class declarations of parameterized types,
e.g., "int a[n];" where n is a variable...  but lacking that, even [1] isn't
very offensive to me.

>Preston Briggs				looking for the great leap forward
>preston@titan.rice.edu

Well, I usually agree with you, Preston, but I think your "Fortran is easy
to understand" bias is showing on this one.  ;-)

						-hankd@ecn.purdue.edu