Ambiguity in definition of setjmp/longjmp makes them much less useful

Michael Meissner meissner at osf.org
Fri Oct 12 04:37:19 AEST 1990


In article <1990Oct09.143521.24019 at unx.sas.com> sasrer at unx.sas.com
(Rodney Radford) writes:

| In article <1597 at redsox.bsw.com> campbell at redsox.bsw.com (Larry Campbell) writes:
| >My real question is this:  Why not define the behavior of setjmp/longjmp so
| >that the values of ALL local variables are defined, whether or not they've
| >been allocated to registers?  Otherwise, setjmp/longjmp are significantly
| >less useful.
| 
| The reason for the ambiguity is because ANSI chose not to make setjmp/longjmp
| functions known by the C compiler so that it just treats them just like any
| other functions (ie: does not force local automatics values from registers
| to storage). ANSI chose not to make any of the functions special case so
| that an application may redefine the functions (although this is frowned upon
| in some cases). The setjmp/longjmp functions themselves do not have the
| required information to force the values from the registers, so we are stuck
| with this oddity.

In some implementations, setjmp could easily get the information if it
so desired.  For example on systems that use MIPS chips (MIPS, SGI,
DECstation, etc.), there is a side table that contains the information
for each function on what registers in the preserved register set are
saved and where they are saved, how to calculate the virtual frame
pointer, etc.  The table can be made to appear in memory by emitting a
specific external.  The 88k computers have a similar facility, though
the table is always in memory.  Longjmp could unwind each stack frame,
and reset the registers until it got back to where it should be, but
that is usually too hard to justify doing to management!
--
Michael Meissner	email: meissner at osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

Do apple growers tell their kids money doesn't grow on bushes?



More information about the Comp.lang.c mailing list