Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #71021

Re: why "int s = setjmp(env)" fails?

From Eric Sosman <esosman@comcast-dot-net.invalid>
Newsgroups comp.lang.c
Subject Re: why "int s = setjmp(env)" fails?
Date 2015-09-21 12:52 -0400
Organization A noiseless patient Spider
Message-ID <mtpch6$a2s$1@dont-email.me> (permalink)
References <d8e6c449-3aad-405e-b8a2-5fa73ee6a9a3@googlegroups.com> <mtm688$rms$1@dont-email.me> <f82143ca-2f45-4ea4-bc78-dc43962cab8b@googlegroups.com>

Show all headers | View raw


On 9/21/2015 11:51 AM, supercat@casperkitty.com wrote:
> On Sunday, September 20, 2015 at 6:47:22 AM UTC-5, Eric Sosman wrote:
>> 	"One proposed requirement on setjmp is that it be usable like
>> 	any other function [...]
>
> Would it have been overly burdensome to allow implementations to properly
> handle one additional case: assigning the result directly to a volatile-
> qualified automatic variable of type "int"?

     The evidence available (the Standard and the Rationale) suggests
that the answer to your question is one of:

	"Yes" -- Some implementor or implementors believed, and
	convinced the others to believe, that it would have been overly
	burdensome.

	"No" -- The authors of the Standard were a bunch of imbeciles,
	not one of whom knew anything about C, compilers, or computers.

     Take your pick.

> Anything one might want to
> do with the result could be done after such assignment, but the usefulness
> of the parameter to "setjmp"

     ITYM the parameter to longjmp().

> is severely limited by an inability to use
> the result more than once.  On a 16-bit system one could obtain the result
> purely within "Standard C" via:
>
>      int result; // Wouldn't even need to be volatile
>      switch(setjmp(env))
>      {
>        case -32767-1: result = -32767-1; break;
>        case -32767: result = -32767; break;
>        case -32766: result = -32766; break;
>        ...65531 lines omitted
>        case 32766: result = 32766; break;
>        case 32767: result = 32767; break;
>      }

     Where is it written that the value returned by setjmp() is the
one and only value available to the code?

	jmp_buf env;
	int result;
	if (setjmp(env) == 0) {
	    do_things(env, &result);
	} else {
	    printf("longjmp'ed for reason #%d\n", result);
	}
	...
	void do_things(jmp_buf env, int *result) {
	    ...
	    // Bail out!
	    *result = 42;
	    longjmp(env, 1);
	}

Observe that `result' could, if desired, be of any (complete) type
at all: int, double, struct foobar, ...

     The fact that a preordained signalling channel is available does
not mean you cannot also use other and less restrictive channels.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

why "int s = setjmp(env)" fails? i@introo.me - 2015-09-19 21:59 -0700
  Re: why "int s = setjmp(env)" fails? Nobody <nobody@nowhere.invalid> - 2015-09-20 10:53 +0100
  Re: why "int s = setjmp(env)" fails? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-20 07:47 -0400
    Re: why "int s = setjmp(env)" fails? supercat@casperkitty.com - 2015-09-21 08:51 -0700
      Re: why "int s = setjmp(env)" fails? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-21 12:52 -0400
        Re: why "int s = setjmp(env)" fails? supercat@casperkitty.com - 2015-09-21 11:44 -0700
          Re: why "int s = setjmp(env)" fails? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-21 15:52 -0400
            Re: why "int s = setjmp(env)" fails? supercat@casperkitty.com - 2015-09-22 11:51 -0700
        Re: why "int s = setjmp(env)" fails? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 17:06 -0700
        Re: why "int s = setjmp(env)" fails? Paul N <gw7rib@aol.com> - 2015-09-28 14:28 -0700
  Re: why "int s = setjmp(env)" fails? Keith Thompson <kst-u@mib.org> - 2015-09-20 07:33 -0700
  Re: why "int s = setjmp(env)" fails? James Kuyper <jameskuyper@verizon.net> - 2015-09-20 11:11 -0400

csiph-web