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)