Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mimsy!oddjob!gargoyle!ihnp4!ho95e!wcs
From: wcs@ho95e.ATT.COM (Bill.Stewart)
Newsgroups: comp.lang.c
Subject: Re: Some questions about ANSI C
Message-ID: <1686@ho95e.ATT.COM>
Date: Fri, 28-Aug-87 22:40:47 EDT
Article-I.D.: ho95e.1686
Posted: Fri Aug 28 22:40:47 1987
Date-Received: Sun, 30-Aug-87 06:47:18 EDT
References: <497@houxs.UUCP> <5080003@hpfcdc.HP.COM>
Reply-To: wcs@ho95e.UUCP (46133-Bill.Stewart,2G218,x0705,)
Distribution: na
Organization: AT&T Bell Labs 46133, Holmdel, NJ
Lines: 16
Keywords: setjump()

In article <5080003@hpfcdc.HP.COM> rml@hpfcdc.HP.COM (Bob Lenk) writes:
: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.

Let's face it, setjmp() is an ugly hack, much uglier than goto.
	#define longjump(x) fprintf(stderr, "Oh, @##$%%$$#!!!!  %s\n", x)
It may be portable outside a Unix\(tm operating system environment,
but it's inherently dependent on stack-like implementations, and
is just as extra-linguistic as I/O.  It's ok to use on occasion, but
don't expect it to have particularly clean semantics.
-- 
#				Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs