Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!labrea!aurora!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!hpcea!hpfcdc!rml
From: rml@hpfcdc.HP.COM (Bob Lenk)
Newsgroups: comp.lang.c
Subject: Re: Some questions about ANSI C
Message-ID: <5080003@hpfcdc.HP.COM>
Date: Thu, 20-Aug-87 17:37:42 EDT
Article-I.D.: hpfcdc.5080003
Posted: Thu Aug 20 17:37:42 1987
Date-Received: Sun, 23-Aug-87 14:38:03 EDT
References: <497@houxs.UUCP>
Organization: HP Ft. Collins, Co.
Lines: 37

> jmp_buf gBlock;
> 
> subr() {
>  char *state;
> 
>  state = "Set up";
>  if( setjmp( gBlock ) ) { printf("Stopped during %s\n", state ); return; }
>  state = "Initialization";
>  initial_processing();
>  state = "First Pass";
>  pass(1);
>  state = "Second Pass";
>  pass(2);
>  state = "Final Pass";
>  pass(3);
>  state = "Termination";
>  shut_down();
>  printf("Wow! we finally succeeded!\n");
> }

According to the public comment draft, optimizing away the last four
assignments to state would be perfectly legitimate.  Reading the
description of longjmp(), it is only makes no guarantees about the
values of automatic variables that are not declared as volatile.  If
state is declared as volatile, the optimizer had better leave it alone
regardless of the setjmp.

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.

The Paris change to setjmp seems unnecessary to me.

		Bob Lenk
		{ihnp4, hplabs}!hpfcla!rml