Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cme!libes From: libes@cme.nist.gov (Don Libes) Newsgroups: comp.std.c Subject: Re: why does setjmp return 1 after longjmp(buf,0)? Message-ID: <6548@muffin.cme.nist.gov> Date: 18 Sep 90 04:09:57 GMT References: <6511@muffin.cme.nist.gov> <13866@smoke.BRL.MIL> <4075@auspex.auspex.com> Reply-To: libes@cme.nist.gov (Don Libes) Organization: National Institute of Standards and Technology Lines: 60 I asked why setjmp returns 1 after longjmp(buf,0). I got some imaginative answers, only one (below) which struck me as having half a chance of being right. I also did a little research. Yes, I really have all these manuals in front of me as I type this.) V6 didn't have setjmp. It had setexit/reset, neither of which took arguments, and which used a single static buffer. ugh. V7 and 4.0BSD setjmp returned 0 after longjmp(buf,0) (according to the manual). Guy Harris reports that the V7 source shows it returned 1 after longjmp(buf,0). Either my manuals predate his sources, or Berkeley coded from documentation that was incorrect. (Probably both true!) S3 (S4, S5) setjmp returned 1 after longjmp(buf,0). ANSI C setjmp returns 1 after longjmp(buf,0). Some people agreed with me that the Standard behavior is stooopid, while admittedly being existing practice. No one disagreed or claimed this is a useful feature. A few people told me they had also been bitten by this. The responses I suspect are correct are a paraphrase of the self-described "wild guesses" of Karl Heuer and Scott David Daniels : Often the only information wanted in a setjmp call is whether it is from the initialization or a longjmp. If it had been possible, what would have been defined was "longjmp with one arg causes a non-zero return from the corresponding setjmp; with two args it causes the setjmp to return the second arg." However, as long as longjmp was not treated specially, such semantics were not possible. After the "improvement", programmers didn't have to "bother" with coding the 2nd argument at the price of not being able to return 0. You may find this hard to swallow, but then you probably never passed uncasted 0's either. I think both of these are the mark of thoughtless programming. The end result is that the Standard accepted this behavior without realizing that it was created for a lousy reason. (Yes, I should've complained sooner.) I still claim that no one in their right mind has or ever will write longjmp(buf,0) knowing that it will return 1. What's even more ironic, is that the entire reason for defining it this way (if this theory is correct), is that being able to write "longjmp(buf)" is now illegal! By the way, no one answered my second question either. Although Karl Heuer evidentally knows, he wouldn't tell. >>Oh, and as long as I'm getting my burning questions answered, what >>does PJ stand for? >If you knew, you'd respect his decision to always use his initials. :-) Don Libes libes@cme.nist.gov ...!uunet!cme-durer!libes