Path: utzoo!utgpu!watmath!uunet!cbmvax!ditto
From: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Newsgroups: unix-pc.general
Subject: Re: Gcc 1.26 available for anonymous Internet FTP
Summary: setjmp/longjmp do save/restore registers
Keywords: gcc setjmp
Message-ID: <5447@cbmvax.UUCP>
Date: 6 Dec 88 06:08:50 GMT
References: <444@manta.pha.pa.us> <11760@cup.portal.com> <1375@umbc3.UMD.EDU> <10628@stb.UUCP>
Reply-To: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Distribution: unix-pc
Organization: Commodore Technology, West Chester, PA
Lines: 30

In article <10628@stb.UUCP> michael@stb.UUCP (Michael) writes:
>In article <1375@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes:
>>restructuring, etc. gcc is particlarly obnoxious with regard to setjmp() /
>>longjmp(), because of the way variables are placed in registers (which
>>are *not* saved/restored by setjmp()/longjmp().
>
>W h a t ? Setjmp/longjmp take a jmpbuf as an argument; in every 68000 system
>I've seen, this is an array big enough to store a movem d0-d7/a0-a6 (13
>longs).

You're correct.

Despite his asterisk-emphasized "*not*", I think Alex knew what he
was saying but just got the polarity of his sentence backward :-).
setjmp/longjmp *do* save/restore registers, and that is, indirectly,
what makes some programs break.

Some code assumes that all variables which are *not* declared as
"register" will *not* be saved/restored by setjmp/longjmp.  This
is true with simple-minded compilers, but it is not true of gcc,
and ANSI C specifies that *no* assumptions may be made about this
behavior.  In fact, I think it says that values of any automatic
variables are undefined after setjmp() returns via longjmp().
-- 
					-=] Ford [=-

"The number of Unix installations	(In Real Life:  Mike Ditto)
has grown to 10, with more expected."	ford@kenobi.cts.com
- The Unix Programmer's Manual,		...!sdcsvax!crash!elgar!ford
  2nd Edition, June, 1972.		ditto@cbmvax.commodore.com