Path: utzoo!attcan!uunet!lll-winken!ames!ncar!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Behaviour of setjmp/longjmp and registers
Message-ID: <15599@mimsy.UUCP>
Date: 24 Jan 89 09:13:32 GMT
References: <25@torsqnt.UUCP> <8867@bloom-beacon.MIT.EDU> <7249@polyslo.CalPoly.EDU>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 31

In article <7249@polyslo.CalPoly.EDU> cquenel@polyslo.CalPoly.EDU
(101 more school days) writes:
>I see [making registers work as well as automatics around setjmp/longjmp]
>as a BAD thing to try to guarantee.

and bases this argument on the idea that `register' is a compiler hint
and need not actually use a machine register.

>As a compiler writer, it certainly makes sense to me to only implement
>what can be guaranteed. ...

But the contents of *all* automatic variables (register or not) *can* be
guaranteed without too much trouble, and without requiring `volatile'
qualifiers.

If you will accept as the definition of a `very good' compiler `one that
does interprocedural analysis and register allocation', then a good compiler
must (since it may allocate registers to variables that are not automatic)
make guarantees that will stand up for automatic variables even in the
presence of longjmp, and the problem vanishes entirely.  So a very good
compiler will make such guarantees.  Other compilers could simply turn
off optimisation in functions containing calls to setjmp().

>I think this newer definition of setjmp/longjmp is much cleaner
>and provides only what is necessary and most useful.

This is a separate (and much more sensible) line of argument with
which I happen not to agree: opinion as to elegance.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris