jackiw@cs.swarthmore.edu (Nick Jackiw) (05/25/90)
Here's an annoying discrepancy I turned up in THINK Pascal (v3.0), which
can cause run-time behavior in the environment to differ from behavior
in a compiled application.
If you're doing some pointer arithmetic such as
with aPtr^ do
aPtr:=Ptr(ord(aPtr)+x+y+z)
where x, y, and z are fields of whatever aPtr pointed to, they may or
may not be valid when the compiler sums the r-expr. When running with
the debug option, I guess the entire right expression is generated and
then assigned to aPtr. This is proper...otherwise, statements like
x:=x*3+x*4 would have undefined results, because the value of the "x"
in x*3 and x*4 would depend upon which way the compiler optimized the
addition.
However, when the debugger option is off, the above statement gets
compiled using the register which holds aPtr both to access the
fields x, y, and z, *and* to hold the sum-in-progress. This means
that, if the additions are carried out x, y, z, ord(aPtr)+x gets
evaluated fine, but then aPtr^.y refers to the place x-bytes in memory
past where it should (because x has been already added to aPtr), and
aPtr^.z is off by x+y.
I'm not sure I'm correct in saying this is a *bug*--I don't know what
the Pascal definition says in this case--but if it's not a bug in
pascal, it might be a bug in your code, so watch out.
--
+-------------------+-jackiw@cs.swarthmore.edu / !rutgers!bpa!swatsun!jackiw-+
| nicholas jackiw | jackiw%campus.swarthmore.edu@swarthmr.bitnet |
+-------------------+-VGP/MathDept/Swarthmore College, Swarthmore, PA 19081--+
"Ah...I've got this CHRONIC pain." _True Believer_hal@krishna.cs.cornell.edu (Hal Perkins) (05/26/90)
In article <XCFKSY@xavier.swarthmore.edu> Nick Jackiw writes: >Here's an annoying discrepancy I turned up in THINK Pascal (v3.0), which >can cause run-time behavior in the environment to differ from behavior >in a compiled application. [sample code whose behavior changes] > with aPtr^ do > aPtr:=Ptr(ord(aPtr)+x+y+z) > >where x, y, and z are fields of whatever aPtr pointed to, they may or >may not be valid when the compiler sums the r-expr. > >I'm not sure I'm correct in saying this is a *bug*--I don't know what >the Pascal definition says in this case--but if it's not a bug in >pascal, it might be a bug in your code, so watch out. The only bug here is that whoever wrote this code doesn't know Pascal well enough. Standard Pascal says that in the statement with e do s the statement s may not modify any of the variables referenced in the expression e. This is precisely to permit the compiler to optimize the statement by keeping the pointer expression in a register or whatever else is helpful. Hal Perkins hal@cs.cornell.edu Cornell CS
jackiw@cs.swarthmore.edu (Nick Jackiw) (05/26/90)
I write: > I'm not sure I'm correct in saying this is a *bug*--I don't know what > the Pascal definition says in this case--but if it's not a bug in > pascal, it might be a bug in your code, so watch out. > Kurt W. Hirchert points out to me that the Pascal standard says that you shouldn't modify the referent of a 'with' in the scope of its 'do', so this is *my* error, not Pascal's. Sorry. (My program has lots of other errors in it, which I could post, too...) Regardless, THINK Pascal users might wish to note the details of my 'bug', as it is involves a significant difference between running under the environment and running stand-alone. -Nick -- +-------------------+-jackiw@cs.swarthmore.edu / !rutgers!bpa!swatsun!jackiw-+ | nicholas jackiw | jackiw%campus.swarthmore.edu@swarthmr.bitnet | +-------------------+-VGP/MathDept/Swarthmore College, Swarthmore, PA 19081--+ "Ah...I've got this CHRONIC pain." _True Believer_