Path: utzoo!attcan!uunet!cs.utexas.edu!usc!rutgers!psuvax1!xavier!news From: jackiw@cs.swarthmore.edu (Nick Jackiw) Newsgroups: comp.sys.mac.programmer Subject: LSP 3.0 bug(?) Message-ID: Date: 25 May 90 16:16:03 GMT Sender: news@xavier.swarthmore.edu (Usenet News) Organization: Visual Geometry Project, Swarthmore College, PA Lines: 37 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_