Path: utzoo!attcan!uunet!dino!ux1.cso.uiuc.edu!iuvax!mailrus!cornell!hal
From: hal@krishna.cs.cornell.edu (Hal Perkins)
Newsgroups: comp.sys.mac.programmer
Subject: Re: LSP 3.0 bug(?)
Message-ID: <41440@cornell.UUCP>
Date: 25 May 90 18:29:50 GMT
References: <XCFKSY@xavier.swarthmore.edu>
Sender: nobody@cornell.UUCP
Reply-To: hal@cs.cornell.edu (Hal Perkins)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 29

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