Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!hplabs!oliveb!ios!qubix!sun!gnu From: gnu@sun.uucp (John Gilmore) Newsgroups: net.lang.c Subject: Re: setjmp: read the manual Message-ID: <1735@sun.uucp> Date: Wed, 10-Oct-84 03:49:54 EDT Article-I.D.: sun.1735 Posted: Wed Oct 10 03:49:54 1984 Date-Received: Mon, 15-Oct-84 01:46:22 EDT References: <1045@research.UUCP> Organization: Sun Microsystems, Inc. Lines: 43 dmr says: > V7, 4.[01]BSD, and SVr0 manuals include this sentence in the setjmp/longjmp > documentation (setjmp(3): "All accessible data have values as of the time > longjmp was called." ... (This is nontrivial, because the > place where the register that contained x was saved can be anywhere in > call chain.) > > There is a very good reason for doing it this way: it makes > register and automatic variables behave the same. > > I checked the behavior on V8, 4.2BSD, and SVr2. It works right > (prints 2) on V8 and 4.2, works wrong (prints 1) on SV (on VAX, 3B20, 3B2). > I don't have 4.2 or SVr2 manuals at hand so I don't know what they say. > > Dennis Ritchie There's a good reason for doing it the other way: efficiency. The Sun (4.2 on 68010's) setjmp(3) says: "All memory-bound data have values as of the time longjmp was called. The machine registers are restored to the values they had at the time setjmp was called. But, because the register storage class is only a hint to the C compiler, variables declared as register variables may not necessarily be assigned to machine registers, so their values are unpredictable after a longjmp. This is especially a problem for programmers trying to write machine- independent C routines." We looked hard at this and decided to change the meaning of setjmp/longjmp (to the above) rather than having EVERY function save enough information to restore the registers to the desired state in case the function's caller did a setjmp and some routine we call does a longjmp. On the VAX there is a call instruction that dumps all this stuff on the stack for you (slowly; I understand a Modula compiler that avoided the instruction sped itself up by 20%). On the 68000 there is no such whizzo instruction so we were forced to do it efficiently or tell ourselves why not. Longjmp wasn't a good enough reason. Also, some function calls internally generated by the compiler do not use the standard calling sequence (again for efficiency) and this would have to be abandoned too. To fix a program that this breaks, you remove "register" declarations from routines that call setjmp. Not so bad.