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_routin e) (void *);
void *arg;
jmp_buf state;
int stack[1024];
};
struct pcb *pcb_pointer;
pcb_pointer = (struct pcb *) malloc(sizeof(s truct pcb));
if(setjmp(pcb_p ointer->state)) {
current->start_routine( current->arg);
printf("Thread returned\n");
exit(0);
}

[Eric Sosman]

JS wrote:

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.

--
Er*********@sun .com

[Keith Thompson]

Mark Odell <od*******@hotm ail.com> writes:

JS wrote:

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
contemplat e 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.

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.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Robert Bachmann]

JS wrote:

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/wg...69/n869.txt.gz
- Post script
http://www.open-std.org/jtc1/sc22/wg...869/n869.ps.gz
- PDF:
http://www.open-std.org/jtc1/sc22/wg...69/n869.pdf.gz

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

--
Robert Bachmann <ne**@rbach.pri v.at>, PGP-KeyID: 0x8994A748

[Chris Croughton]

On Wed, 23 Mar 2005 18:29:31 -0500, Eric Sosman
<er*********@su n.com> wrote:

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]

On Wed, 23 Mar 2005 17:17:01 -0500, Mark Odell wrote:

Ben Pfaff wrote:

Mark Odell <od*******@hotm ail.com> writes:

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.

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]

Lawrence Kirby wrote:

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.
Yeah but that breaks my "no numbers except zero" rule. :-) Besides,
sometimes 1 looks like l (ell).

! 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.

--
- Mark

[Chris Croughton]

On Thu, 24 Mar 2005 08:51:51 -0500, Mark Odell
<od*******@hotm ail.com> wrote:

Lawrence Kirby wrote:

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?

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[i] = 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]

Lawrence Kirby wrote:

On Wed, 23 Mar 2005 17:17:01 -0500, Mark Odell wrote:

Ben Pfaff wrote:

Mark Odell <od*******@hotm ail.com> writes:

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.

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

! 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/>

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Ben Pfaff]

Chris Croughton <ch***@keristor .net> writes:

[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.
--
"Large amounts of money tend to quench any scruples I might be having."
-- Stephan Wilms

[Richard Bos]

Robert Bachmann <ne**@rbach.pri v.at> wrote:

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