chris@mimsy.UUCP (Chris Torek) (09/25/88)
[Thanks to Jim Giles for a wonderful phrase for a subject line] In article <4151@lanl.gov> jlg@lanl.gov (Jim Giles) notes that a pointer >... rasies the spectre of aliasing in contexts where it doesn't exist >if the pointer isn't user accessible. Unfortunately, even if the pointer is hidden, the spectre itself remains. I will use some pseudo-Fortran with a slightly compressed ratfor-ish syntax to show what I mean: type data_t = real # or whatever subroutine work(in, out, n) int n; data_t in(n), out(in) do i = 1, n { out(i) = <vectored function of in(i)> } end program p data_t array(35) int i call setup(array, 1, 10) # set up initial data call work(array(1), array(11), 10) # munch once call work(array(11), array(21), 10) # and again call work(arraay(21), array(26), 5) # and a bit more >>> call work(array(21), array(26), 10) # and then again with overlap print *, array(1..35) end The call marked `>>>' is in fact illegal in F77, but if I hid it better (perhaps disguising the constants with function calls would suffice), it would be very difficult for a compiler to discover this at compile time. Most simply assume that that call is proper, and produce `mysterious' results: the program works on a VAX and fails on a CDC. The reason it sometimes fails is, of course, aliasing. F77 prohibits it; C allows it; ANSI X3J11 tried to come up with a compromise, but aliasing is so prevalent in existing correct C code that standardising a solution without first testing it is much too obvious a mistake. (No doubt vendors will provide their own ways of allowing vectorisation of C code: probably all different, but in a few years one solution will probably win out and become a part of the next standard, rather like pointers and data structures in F77....) Aliasing can happen without explicit pointers, as I demonstrated above. Fortran's solution is just like C's solution to the side effects problem exemplified by `i = i++': declare it illegal and hope that programmers will not do it. I find this solution distasteful, but there it is. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris