Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!adm!news
From: CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl Brendel)
Newsgroups: comp.lang.pascal
Subject: Re: IMPLEMENT GOTO ACROSS MODULES IN TURBO PASCAL??
Message-ID: <25439@adm.brl.mil>
Date: 8 Jan 91 22:03:40 GMT
Sender: news@adm.brl.mil
Lines: 44

In article <11661@j.cc.purdue.edu>, zhou@brazil.psych.purdue.edu
  (Albert Zhou) wrote:

>Any other solutions so far I've seen need quite a little extra work
>than if a direct goto statement can be implemented.

[...deleted...]

>My point is, let programmers to control their own programming style.
>And some "bad" practice can be the only good solution under
>exceptional case.
>
>Or a compiler directive (see G+) can be setup to enforce the rule of
>using goto directly. Just like range check.

The "LongJump" solution takes no more work on the programmer's part
(once the appropriate unit has been inserted into the USES
statement) than your desired Goto would: To use a Goto, you must
declare and use a label, then you must call the Goto as required; to
use a LongJump, you must declare a JumpRecord, call SetLongJump,
then call LongJump as required. (As in my second reply, I'm using
Turbo Professional terminology here.)

The fact of the matter is that a _pure_ Goto outside of a routine is
not feasible in a language like Pascal. What happens to the stack
frame of the routine you are going from? How is the stack frame
created for the routine you are going to? And what happens to the
stack frames of routines which were pending returns when you made
the Goto?

The LongJump approach deals with these matters by saving and
restoring a specific stack frame. Even then, there are limitations
(which don't affect your proposed use): you can jump from a lower
stack frame to a higher one, but not vice versa. (I.e., you can jump
"back", but not "forward".)

Cheers--

+--------------------------------------------------------------------+
| Karl Brendel                           Centers for Disease Control |
| Internet: CDCKAB@EMUVM1.BITNET         Epidemiology Program Office |
| Bitnet: CDCKAB@EMUVM1                  Atlanta, GA, USA            |
|                        Home of Epi Info 5.0                        |
+--------------------------------------------------------------------+