🚀 go-pugleaf

In article <3791@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>> In article  <3681@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>> ]Really?  I don't know _any_ language that has pointers that places
>> ]bounds on where it can point.

	Pascal:  can only point to specially allocated storage
		[ie, no equivalent to "int i, *pi = &i;"]
	Algol: cannot point to objects of narrower scope
		[eg, the equivalent of "int *pi; f() { int i; pi = &i; }"
		 is illegal]

>With pointers, [...] The compiler _can't_ make any simple automatic bounds
>checks (although, in C it can perhaps automatically limit index
>calculations).

	Well, it's only non-simple in the case you describe elsewhere of
address punning through casts;  these are (or ought to be) rare enough
that a non-trivial check [eg, by tagging] has only marginal effects on
the efficiency.  Older readers will recall that it used to be *extremely
normal* to test programs with a whole battery of checks "enabled", with
a consequent large penalty in run-time speed, and to disable the checks
for "production runs".  If it is unacceptable these days to disable the
checks, then the answer is to provide them in hardware, as we used to
in the 50s and 60s.

>Variables _not_ in this "family"
	[of declared-to-be-alias-able variables]
>				  are _known_ not to be aliased to
>anything within it

	Yes, but one trouble is that one of the commonest cases in
practice is where a variable is aliassed with itself, as in a[i] v. a[j].
Checking that i != j can plainly only be done, in general, at run-time.
It gets worse when you are worried about a[j] v. b[j] where a, b and j
are parameters to some procedure -- you plainly need to be sure that
a != b [and it gets worse in languages that allow slicing and other
subsetting of arrays], which again involves arbitrarily messy checks if
a and b are potentially inherited from further procedures and you insist
that the checks be carried out by compiler and loader.  The problems
will only be exacerbated if you deprive programmers of natural ways of
using pointers, so that they find themselves [through brute force or
ignorance] emulating proper data structures by indexing into arrays.

	You are right that in many cases pointerless code can help
the compiler by making certain aliasses impossible;  on the other
hand, in most if not all of the cases where this matters, the
compiler can make the same deductions given a program which is
properly divided into modules and in which scope rules are enforced.

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk