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