🚀 go-pugleaf

> i discovered an bug, when gcc -g -O removed (optimized) a statement. It
> removes count-- from the example.

ANSI C does not require setjmp() to preserve local variables unless
they are "volatile".

>From the bottom of page 254 of K&R 2:

> Accessible objects have the values they had when "longjmp" was
> called, except that non-"volatile" automatic variables in the
> function calling "setjmp" become undefined if they were changed
> after the "setjmp" call.

Since your change to "count" occurs after the "setjmp" call, the
variable is undefined and so "count--" can just as well be removed.

Michael Salmon pointed out:
> While this is undoubtably frustrating I don't see how gcc can be
> expected to understand your function without including setjmp as an
> element of the language.

I believe the standard allows this precisely so that the compiler
doesn't have to know about the special properties of "setjmp", but
I wouldn't be surprised if some machines' libraries take advantage
of this fact and save some time by not restoring variables that
appear in registers.  Even if GCC did know about setjmp, it wouldn't
be able to assume the variable had a reliable value here, so again,
it might as well remove the statement.

To fix your problem, change the declaration "count" to:

> volatile int  count;

"Volatile" means, more or less, "something funny is happening here
so compile all references to this object literally even if it looks
like they can be optimized."

								-- Dave