why does setjmp return 1 after longjmp(buf,0)?

[John Cowan]

In article <13866 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>In article <6511 at muffin.cme.nist.gov> libes at cme.nist.gov (Don Libes) writes:
>>Was there any discussion about "fixing" this?
>
>I don't recall any, because it not only reflected existing practice,
>it also is obviously essential to prevent a longjmp from returning to
>the wrong branch of the setjmp return path.

I was bitten by this misfeature once, and had to code around it.

The context was that of a complex operation which could succeed, fail, or
find resource exhaustion.  In the last case, the right thing to do was to
retry the entire operation, by which time the exhaustion would have cleared.

I attempted to implement SUCCESS as "return", FAILURE as "longjmp(buff,1)"
and RETRY as "longjmp(buff,0)".  I reasoned that the last case would cause
a return to the "setjmp" point before the operation began but with a value
of zero, which would cause the operation to begin as if this were the first
time.  Unfortunately, the operation never got retried!

I finally found the relevant line in longjmp(3).  Cursing, I recoded
RETRY as "longjmp(buff,2)" and changed the setjmp conditional from
"if(setjmp(buff)) { main code } else { failure code}" to
"if(setjmp(buff) != 1)".

I know that the ANS put some restrictions on where you can put setjmp()
calls.  Is the above legal ANSI C?  In other words, can you compare the
results of setjmp for non-equality with a constant value?
-- 
cowan at marob.masa.com			(aka ...!hombre!marob!cowan)
			e'osai ko sarji la lojban