Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uiucdcsb!kenny
From: kenny@uiucdcsb.cs.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: Some questions about ANSI C
Message-ID: <165600009@uiucdcsb>
Date: Fri, 28-Aug-87 13:39:00 EDT
Article-I.D.: uiucdcsb.165600009
Posted: Fri Aug 28 13:39:00 1987
Date-Received: Sun, 30-Aug-87 07:56:31 EDT
References: <524@myrias.UUCP>
Lines: 27
Nf-ID: #R:myrias.UUCP:524:uiucdcsb:165600009:000:1293
Nf-From: uiucdcsb.cs.uiuc.edu!kenny    Aug 28 12:39:00 1987


/* Written  2:16 am  Aug 24, 1987 by cmt@myrias.UUCP in uiucdcsb:comp.lang.c */
/* ---------- "Re: Some questions about ANSI C" ---------- */
> As for the arguments about taking the address of setjmp, the draft
> also said (under "environmental constraint") that the only context in
> which setjmp can portably appear is comparison to an integral constant
> expression.  This seems to mean that no true setjmp() function had to
> exist, even before the Paris change.
> 		Bob Lenk

Not true.  You could still have a call via a function pointer that points
at setjmp() in a comparison context.  This means that every indirect call
of appropriate type in a comparison context might be a call to setjmp.
And that's just for correct programs.  What happens if any old indirect
call could be a (possibly erroneous) call to setjmp()?  How much work
should be done to do something sensible in every such case?

Life is much simpler if you always know when a setjump() is being done.
-- 
Chris Thomson, Myrias Research Corporation	   alberta!myrias!cmt
200 10328 81 Ave, Edmonton Alberta, Canada	   403-432-1616
/* End of text from uiucdcsb:comp.lang.c */

Uh, no.  If you can't use setjmp() except in the context of comparing
it to an integer, then how did you get a pointer to it to begin with?

kBk