Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!samsung!spool2.mu.edu!uunet!saxony!dgil From: dgil@pa.reuter.COM (Dave Gillett) Newsgroups: comp.lang.pascal Subject: Turbo bug with VAR parameters Keywords: bug,var,borland Message-ID: <683@saxony.pa.reuter.COM> Date: 29 Jan 91 01:22:08 GMT Distribution: na Organization: Reuter:file Inc (A Reuter Company) Palo Alto, CA Lines: 44 Consider the following trivial example: var Global : String [255]; procedure Foo (VAR FooStr : String [255]); begin FooStr := 'abcdefghijklmnopqrstuvwxyz'; end { Foo }; procedure Bar (VAR BarStr : String [255]); begin Foo (BarStr); end { Bar }; begin Bar (Global); end. When I compile this using version 5.5 of Turbo Pascal (okay, this might be fixed in 6.0 for all I know), Foo gets compiled to access FooStr by reference rather than by value; apparently, as a pointer back into the previous stack frame. Similarly, Bar gets compiled to generate such access for BarStr. The problem is that, at run-time, Foo trashes Bar's stack frame, instead of reaching all the way back to the global context to resolve FooStr -> Global. I can understand that at the point that Foo is being compiled, it cannot tell what the calling stack will look like. And presumably the code to look back a single level can easily be generated inline and is pretty efficient. So generating "correct" code for this case may be impractical. However: When Bar is being compiled, the compiler *must* already know that Foo expects a VAR argument (it does other kinds of type-checking on the call!). And so if the compiler cannot generate correct code for this case, it's not unreasonable to expect *at least* a diagnostic warning that the passing of VAR parameters as VAR parameters is not supported. It *is* unreasonable to expect the programmer not only to manually program around this (via trivial use of temporaries), but also manually diagnose and locate instances of this. Dave