[comp.sys.mac.programmer] THINK C: longjmp through methods?

pepke@gw.scri.fsu.edu (Eric Pepke) (08/18/90)

Here's one for Rich and the rest of the THINK C gurus.

Is it safe to do a setjmp/longjmp through a series of object messages the 
same way one can do it through a series of function calls, or is there 
Memory Manager stuff in the method chain that will be vulnerable?

Application: a top-down compiler that for some imponderable reason I 
decided to implement as methods.  I want to have a command-period 
compilation abort without having to do an unwind everywhere.

Eric Pepke                                    INTERNET: pepke@gw.scri.fsu.edu
Supercomputer Computations Research Institute MFENET:   pepke@fsu
Florida State University                      SPAN:     scri::pepke
Tallahassee, FL 32306-4052                    BITNET:   pepke@fsu

Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.

siegel@endor.harvard.edu (Rich Siegel) (08/18/90)

In article <423@sun13.scri.fsu.edu> pepke@gw.scri.fsu.edu (Eric Pepke) writes:
>Here's one for Rich and the rest of the THINK C gurus.
>
>Is it safe to do a setjmp/longjmp through a series of object messages the 
>same way one can do it through a series of function calls, or is there 
>Memory Manager stuff in the method chain that will be vulnerable?

	For all intents and purposes, longjmp'ing through the method chain
is the same as longjmp'ing through an ordinary call chain.

>Application: a top-down compiler that for some imponderable reason I 
>decided to implement as methods.  I want to have a command-period 
>compilation abort without having to do an unwind everywhere.

	You'll probably want to longjmp through to several points; you
won't have to unwind *everywhere*, but you'll almost certainly want to
clean up any temporary allocations...

	The UFailure mechanism from MacApp is an elegant solution to this
problem; with some hacking, it can be adapted for use in C...

R.
~~~~~~~~~~~~~~~
 Rich Siegel
 Staff Software Developer
 Symantec Corporation, Language Products Group
 Internet: siegel@endor.harvard.edu
 UUCP: ..harvard!endor!siegel

"Who could sleep when there's a hunk with no clothes on wandering around
at five in the morning, knocking over furniture?"

~~~~~~~~~~~~~~~

pepke@gw.scri.fsu.edu (Eric Pepke) (08/20/90)

In article <3940@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel) 
writes:
>         You'll probably want to longjmp through to several points; you
> won't have to unwind *everywhere*, but you'll almost certainly want to
> clean up any temporary allocations...

Thanks.  I'm handling this a different way, by anchoring all temporary 
allocations to the link file.

Eric Pepke                                    INTERNET: pepke@gw.scri.fsu.edu
Supercomputer Computations Research Institute MFENET:   pepke@fsu
Florida State University                      SPAN:     scri::pepke
Tallahassee, FL 32306-4052                    BITNET:   pepke@fsu

Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.