Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!genrad!mit-eddie!godot!ima!ism780b!jim From: jim@ism780b.UUCP Newsgroups: net.lang.c Subject: Re: Re: setjmp: read the manual Message-ID: <69@ism780b.UUCP> Date: Thu, 18-Oct-84 00:31:46 EDT Article-I.D.: ism780b.69 Posted: Thu Oct 18 00:31:46 1984 Date-Received: Fri, 19-Oct-84 06:38:40 EDT Lines: 0 Nf-ID: #R:sun:-173500:ism780b:25500042:000:976 Nf-From: ism780b!jim Oct 16 19:43:00 1984 >There's a good reason for doing it the other way: efficiency. Since when is efficiency an issue in regard to setjmp/longjmp? >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." I wouldn't let anyone who write such garbledy-goop anywhere near my manuals. Why not just say the values of register variables local to a setjmp call are unpredictable following a return via longjmp, period? -- Jim Balter, INTERACTIVE Systems (ima!jim)