longjmp spec

[Noob]

Hello,

The spec for longjmp states:

After longjmp is completed, program execution continues as if the
corresponding invocation of the setjmp macro had just returned the
value specified by val. The longjmp function cannot cause the setjmp
macro to return the value 0; if val is 0, the setjmp macro returns the
value 1.

This means longjmp has to do something along the lines of

return (val != 0) ? val : 1;

Another possibility would have been to specify that calling longjmp
with a value of 0 had undefined behavior.

Does anyone know why the ANSI chose to make a special case
for longjmp(env, 0) ??

Was it because most implementations circa 1988 worked that way?

Regards.

 

[Moi]

Hello,

The spec for longjmp states:

After longjmp is completed, program execution continues as if the
corresponding invocation of the setjmp macro had just returned the value
specified by val. The longjmp function cannot cause the setjmp macro to
return the value 0; if val is 0, the setjmp macro returns the value 1.

This means longjmp has to do something along the lines of

return (val != 0) ? val : 1;

Another possibility would have been to specify that calling longjmp with
a value of 0 had undefined behavior.

Does anyone know why the ANSI chose to make a special case for
longjmp(env, 0) ??

Because setjmp returns 0 when it set the jump.
The calling code must be able to distinguish (at least) two cases)

jmp_buf zebuff;

switch (setjmp(zebuff)) {
case 0: /* jump position was set successfully */
break;
default: /* someone tripped the wire */
...
break;
}

Was it because most implementations circa 1988 worked that way?

To me, the zero return seems a very logical choice,
allowing it to be used as an expression in an if() or a switch() statement,

-1 could have been chosen as well, but that is more or less
associated with error returns.


HTH,
AvK

 

[Noob]

Hello AvK,

I think you've misread my question.

Because setjmp returns 0 when it set the jump.

Right.

setjmp returns 0 when the context has been saved; and it returns
the second parameter of longjmp (val) when the context has been
restored.

int setjmp(jmp_buf env)
void longjmp(jmp_buf env, int val);

Obviously, there is a problem when one calls longjmp(env, 0)

ANSI's solution was to require that the implementation of
longjmp return 1 when val is 0.

which is why I wrote"return (val != 0) ? val : 1;"

Another solution would have been to simply make that situation
undefined behavior. (The same way strlen(NULL) has UB.)

Regards.

 

[Noob]

The spec for longjmp states:

After longjmp is completed, program execution continues as if the
corresponding invocation of the setjmp macro had just returned the
value specified by val. The longjmp function cannot cause the setjmp
macro to return the value 0; if val is 0, the setjmp macro returns the
value 1.

This means longjmp has to do something along the lines of

return (val != 0) ? val : 1;

Another possibility would have been to specify that calling longjmp
with a value of 0 had undefined behavior.

Does anyone know why [C89] chose to make a special case
for longjmp(env, 0) ??

Was it because most implementations circa 1988 worked that way?

Did K&R C already treat longjmp(env, 0) as a special case?

Regards.

 

[Eric Sosman]

Did K&R C already treat longjmp(env, 0) as a special case?

The index of K&R contains neither setjmp nor longjmp.

 

[Ben Bacarisse]

Noob wrote:

Did K&R C already treat longjmp(env, 0) as a special case?

As Eric has pointed out, neither setjmp nor longjmp were part of C when
C&R was written. However, they were part of the most common environment
in which C was written so we can find out the state of the functions at
about that time. The Unix V7 manuals[1] don't treat longjmp(..., 0) as
being any more special than it obviously is. It is not singled out as
something that can go wrong so one might assume it is implicitly
permitted though the logical peculiarity of doing so is there for all to
read.

A scan of some of my old code from that date suggests that I often used
!0 as the second parameter to longjmp but there is one use of 0. There
is a comment: /* return to the main loop after this error */ so
fortunately I felt I should document this oddity.

By the way, why do you care about this special case?

[1] From about 1979 a shade later than K&R. The 6th edition (about
1972) has no reference to setjmp and longjmp.