using setjmp

[JS]

When setjmp is called how can the if statement evaluate to true or false
when setjmp only returns 0 or non-zero?


struct pcb {
void *(*start_routine) (void *);
void *arg;
jmp_buf state;
int stack[1024];
};


struct pcb *pcb_pointer;
pcb_pointer = (struct pcb *) malloc(sizeof(struct pcb));


if(setjmp(pcb_pointer->state)) {
current->start_routine(current->arg);
printf("Thread returned\n");
exit(0);
}

 

[Dave Vandervies]

When setjmp is called how can the if statement evaluate to true or false
when setjmp only returns 0 or non-zero?

Have a coffee, go outside, and sit under a tree (or, if the weather
fails to be cooperative, at least get away from the computer), and
contemplate the difference between true/false and nonzero/zero, and you
will be enlightened.


dave

--
Dave Vandervies (e-mail address removed)

The Kremlin has a mother these days?

After a fflush(stdin), it might end up having three mothers.
--Joona I Palaste and Gordon Burditt in comp.lang.c

 

[Gordon Burditt]

When setjmp is called how can the if statement evaluate to true or false

when setjmp only returns 0 or non-zero?

There is no true or false in C89. if statements execute the "then" clause
(even though there's no "then" keyword) if the condition evaluates to
non-zero.

While C99 has true and false, this has nothing to do with if statements.

Gordon L. Burditt

 

[JS]

Have a coffee, go outside, and sit under a tree (or, if the weather
fails to be cooperative, at least get away from the computer), and
contemplate the difference between true/false and nonzero/zero, and you
will be enlightened.

Well I have only Java experience and not yet found anything about this
definition in K&R.

 

[JS]

There is no true or false in C89. if statements execute the "then" clause
(even though there's no "then" keyword) if the condition evaluates to
non-zero.

While C99 has true and false, this has nothing to do with if statements.

Gordon L. Burditt

Where can I find C89 and C99??

 

[Mark Odell]

Well I have only Java experience and not yet found anything about this
definition in K&R.

I have found that 0 (zero) and !0 (not zero) work well for false and
true checking.

 

[Ben Pfaff]

I have found that 0 (zero) and !0 (not zero) work well for false and
true checking.

I have found that 1 works well as !0.

 

[Mark Odell]

I have found that 1 works well as !0.

Yeah but that breaks my "no numbers except zero" rule. Besides,
sometimes 1 looks like l (ell).

 

[JS]

I found this example:

#include <setjmp.h>
#include <stdio.h>

jmp_buf ex;

static int foo (int a, int b)
{
if (!b)
longjmp (ex, 1); /* THROW */
else
return a/b;
}

int main (void)
{
int x = 0, y = 1, z = 0;
if (setjmp (ex) == 0) /* TRY : longjmp branches back to here */
{
x = foo(y, z);
}
else /* CATCH */
{
printf ("Exception: attempt to divide by zero\n");
}
}

When foo is called after setjmp has been called, longjmp is called. Then
control jumps to setjmp but this time setjmp does not return 0 and
therefore: printf ("Exception: attempt to divide by zero\n"); is executed.

But I don't understand why setjmp don't return 0 after the longjmp call. Is
it because the second parameter to longjmp is used as the return value for
setjmp?

Or does the second paramter replace 0 in: if (setjmp (ex) == 0)?

 

[Martin Ambuhl]

When setjmp is called how can the if statement evaluate to true or false
when setjmp only returns 0 or non-zero?

Since false is 0 and true is non-zero, I fail to see your problem.

 

[Eric Sosman]

I found this example:

#include <setjmp.h>
#include <stdio.h>

jmp_buf ex;

static int foo (int a, int b)
{
if (!b)
longjmp (ex, 1); /* THROW */
else
return a/b;
}

int main (void)
{
int x = 0, y = 1, z = 0;
if (setjmp (ex) == 0) /* TRY : longjmp branches back to here */
{
x = foo(y, z);
}
else /* CATCH */
{
printf ("Exception: attempt to divide by zero\n");
}
}

When foo is called after setjmp has been called, longjmp is called. Then
control jumps to setjmp but this time setjmp does not return 0 and
therefore: printf ("Exception: attempt to divide by zero\n"); is executed.

But I don't understand why setjmp don't return 0 after the longjmp call. Is
it because the second parameter to longjmp is used as the return value for
setjmp?

Or does the second paramter replace 0 in: if (setjmp (ex) == 0)?

setjmp() is very peculiar. You call it like an ordinary
function, and it returns a value of zero. But if you later
call longjmp(), setjmp() returns a second time even though it
has not been called a second time. On this second return, it
yields the value that was given to longjmp() (except that
there's a special case: if you hand a zero to longjmp(),
setjmp() returns a one).

It is even possible to call longjmp() more than once,
causing setjmp() to return more than twice. Such tricks are
probably better used for obfuscation than for real code.

 

[Keith Thompson]

I have found that 0 (zero) and !0 (not zero) work well for false and
true checking.

I've found that section 9 of the C FAQ works even better.

Anything that compares equal to 0 is considered false; anything that
compares unequal to 0 is considered true. Declaring your own FALSE
and TRUE values can be useful (if you don't have C99's <stdbool.h>),
but there's no point in doing anything more elaborate than 0 for FALSE
and 1 for TRUE. If you use FALSE and TRUE, use them only as values to
be assigned; never compare a logical value to FALSE or to TRUE
(especially to TRUE); 2 is "true", but it's not equal to TRUE. For
example, never write:
if (cond == TRUE) { ... }
Instead, just write:
if (cond) { ... }

Built-in operators (==, !=, <, et al) always yield 0 or 1, but
functions returning boolean values (like isdigit()) can only be
assumed to return 0 or non-0.

 

[Robert Bachmann]

Where can I find C89 and C99??

Latest draft of the C89 standard:

- Plain text:
http://dev.unicals.com/papers/c89-draft.html
- HTML:
http://dev.unicals.com/papers/c89-draft.html

Latest draft of the C99 standard:

- Plain text:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/n869.txt.gz
- Post script
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/n869.ps.gz
- PDF:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/n869.pdf.gz

You can buy the final C99 standard at:
http://www.iso.org/
http://webstore.ansi.org/

 

[Chris Croughton]

It is even possible to call longjmp() more than once,
causing setjmp() to return more than twice. Such tricks are
probably better used for obfuscation than for real code.

I've seen it used in a type of state machine, something like:

jmp_buf jump;

void top(void)
{
switch (setjmp(jump))
{
case 0:
start();
case 1:
func1();
case 2:
func2();
/* ... */
case n:
funcn();
default:
break;
}
}

where each function either returned (in which case it fell through to
the next state) or it (or more likely a function it called) called
longjmp(jump, i); to go directly to state i. (In practice the states
were all using an enum rather than a literal number, but you get the
idea.) The advantage was that when calling down through a stack of
functions it didn't need a test after each one to see whether it should
return to a higher level, it just went straight there (there was no
local initialisation which needed tidying).

It's not an advised program structure, because it is very easily abused,
but in the circumstances it was rather elegant...

I've also seen it done in an implementation of exceptions in C, to
"re-throw" the exception at the current level, but there it was hidden
in the exception macros...

Chris C

 

[Lawrence Kirby]

Yeah but that breaks my "no numbers except zero" rule. Besides,
sometimes 1 looks like l (ell).

! is also similar.

There are a few numbers that are OK as constants in some circumstances,
including 1 and 10. E.g. y = x+1 is rarely going to be made clearer by
hiding the 1.

Lawrence

 

[Mark Odell]

! is also similar.

But !0 is unlikely to make sense if read as "ell-zero".

There are a few numbers that are OK as constants in some circumstances,
including 1 and 10. E.g. y = x+1 is rarely going to be made clearer by
hiding the 1.

Why + 1 I would ask. Why does 'y' need to be equal to 'x' + 1? How could
such an equation be written more self-explanatory? Clearly this is all
style-nitpicking but fun nonetheless.

 

[Chris Croughton]

Why + 1 I would ask. Why does 'y' need to be equal to 'x' + 1?

Because that's the formula! I often use something like:

y = sqrt(x*x + 1);

Or an index which needs to start at the next element. The 1 is never
going to change to anything else.

How could such an equation be written more self-explanatory?

Very likely it can't, if it's dealing with mathematics. Defining the
constant as ONE is silly, it makes it more obscure.

Clearly this is all style-nitpicking but fun nonetheless.

Another standard code snippet:

for (i = 0; i < n-1; ++i)
arr = arr[i+1];

It's simple to understand, totally portable, and probably just as
efficient as any other form at shifting the contents of an array.
Anything more will make it less understandable, not more.

Using a #define for a complicated constant like PI makes sense (in
particular, it's easy to make it more precise if needed). Using one for
a number which may change makes sense (array limits, for instance).
Using it for the value 1 where it will never change is more confusing
than using a literal...

Chris C

 

[CBFalconer]

! is also similar.

All you really need is #define ten 10. The rest can use (ten/ten)
or (ten-ten) etc. I kid you not. The DAC512 computer used this.
See:

<http://cbfalconer.home.att.net/firstpc/>

 

[Ben Pfaff]

[regarding setjmp/longjmp]

The advantage was that when calling down through a stack of
functions it didn't need a test after each one to see whether it should
return to a higher level, it just went straight there (there was no
local initialisation which needed tidying).

Use of a pool allocator in conjunction with setjmp/longjmp can
simplify code, even if it has many local allocations.

 

[Richard Bos]

You can buy the final C99 standard at:
http://www.iso.org/
http://webstore.ansi.org/

Or, if you want a hard copy at a sane price and with a sane license, at
<http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470845732.html>.

Richard