Has anyone written a library for the setjmp functions?

I know that D has exception handling, but that doesnt allow you to go back down the stack(correct me if im wrong).

imr1984 wrote:
> Has anyone written a library for the setjmp functions? 
> 
> I know that D has exception handling, but that doesnt allow you to go back down
> the stack(correct me if im wrong).
> 
> 

I badly need the setjmp/longjmp functions... for writing obfuscated D code of course.

"imr1984" <imr1984_member@pathlink.com> wrote in message news:d7kmp5$21i4$1@digitaldaemon.com...
> Has anyone written a library for the setjmp functions?
>
> I know that D has exception handling, but that doesnt allow you to go back
> down
> the stack(correct me if im wrong).
>
>

setjump allows to restore state of execution environment including stack using snaphot taken at some point.

setjump is not unwinding stack - it is not calling destructors of auto objects.

And what is wrong with exceptions?

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d7kqfj$255c$1@digitaldaemon.com...
>
> "imr1984" <imr1984_member@pathlink.com> wrote in message news:d7kmp5$21i4$1@digitaldaemon.com...
> > Has anyone written a library for the setjmp functions?
> >
> > I know that D has exception handling, but that doesnt allow you to go
back
> > down
> > the stack(correct me if im wrong).
> >
> >
>
> setjump allows to restore state of execution environment including stack using snaphot taken at some point.
>
> setjump is not unwinding stack - it is not calling destructors of auto objects.
>
> And what is wrong with exceptions?
>

I'm not familiar with setjmp.  Andrews description makes it sounds quite similar to a Lisp continuation.

Is anyone in a position to describe the purpose and method of using setjmps and how they compare to other methods of storing program state such as continuations?

Does it only take a snapshot of the stack, or of the heap, or both?

Hmmm...Maybe I should have shifted this to the D.learn newsgroup.

Thanks.

Tony
Melbourne Australia

In article <d7lpfq$2vnq$1@digitaldaemon.com>, Tony says...
>
>I'm not familiar with setjmp.  Andrews description makes it sounds quite similar to a Lisp continuation.
>
>Is anyone in a position to describe the purpose and method of using setjmps and how they compare to other methods of storing program state such as continuations?
>
>Does it only take a snapshot of the stack, or of the heap, or both?
>
>Hmmm...Maybe I should have shifted this to the D.learn newsgroup.
>
>Thanks.
>
>Tony
>Melbourne Australia
>

Having just recently discovered the magic of setjmp/longjmp function calls, I think I can explain their functionality.  Here goes:

setjmp()/longjmp() do not make any snapshots of your program's state or stack or
heap as far as I know.

Calling setjmp() in your program acts like a fork() call, but does not actually
create any new processes; it's just easiest to think of it this way.  Imagine
your program being forked into two programs:  one program that continues to run
until longjmp() is called and another that sits and waits at your setjmp() call
for the other program to call longjmp().

Basically it's a glorified (?) label/goto.  longjmp() is able to pass a single
integer value back to setjmp() for error-reporting purposes.  Much like the
fork() call, setjmp() returns 0 to continue normal execution upon first call,
but will return the integer parameter passed to longjmp() if longjmp() was
called at any time.  setjmp() simply places a marker on the location of where
the function was called and longjmp() jumps back to that marker.

Here's some example code (written in C, but the concept is the same):

: #include <setjmp.h>
:
: jmp_buf error_context;
:
: int main() {
:   int errval;
:   printf("initial setjmp() call\n");
:   errval = setjmp(error_context);
:   printf("return from setjmp()\n");
:   if (errval == 0) {
:     // This is the initial call without an error.
:
:     printf("generating error\n");
:     // Now let's generate an "error" by calling longjmp()...
:     longjmp(error_context, 1);
:
:   } else {
:     // Execution comes here after the longjmp(). Do you see?
:     // The call to longjmp() effectively returns program state to back when
:     // the setjmp() was called and forces it to return the value passed to
longjmp(),
:     // in this case: 1.
:     printf("errval = %d\n", errval);
:   }
: }

This code should produce the following output:

: initial setjmp() call
: return from setjmp()
: generating error
: return from setjmp()
: errval = 1

I just recently used the sigsetjmp() / siglongjmp() variants of the functions
for signal handling under Linux.  When the system calls a signal handler, you
have very limited functionality; so calling siglongjmp() from a signal handler
will get you back within your program context.  This is useful in detecting
horrible things like SIGSEGV (seg faults) and SIGFPE (floating point errors) so
you can recover from them without much damage!

Hope that helps -

Regards,
James Dunne

"James Dunne" <james.jdunne@gmail.com> wrote in message news:d7n2ig$1c0f$1@digitaldaemon.com...
> In article <d7lpfq$2vnq$1@digitaldaemon.com>, Tony says...
>>
>>I'm not familiar with setjmp.  Andrews description makes it sounds quite similar to a Lisp continuation.
>>
>>Is anyone in a position to describe the purpose and method of using
>>setjmps
>>and how they compare to other methods of storing program state such as
>>continuations?
>>
>>Does it only take a snapshot of the stack, or of the heap, or both?
>>
>>Hmmm...Maybe I should have shifted this to the D.learn newsgroup.
>>
>>Thanks.
>>
>>Tony
>>Melbourne Australia
>>
>
> Having just recently discovered the magic of setjmp/longjmp function
> calls, I
> think I can explain their functionality.  Here goes:
>
> setjmp()/longjmp() do not make any snapshots of your program's state or
> stack or
> heap as far as I know.


<quote src="http://www.icewalkers.com/Linux/ManPages/setjmp-3.html">

setjmp() saves the stack context/environment in
env for later use by longjmp().

</quoute>



>
> Calling setjmp() in your program acts like a fork() call, but does not
> actually
> create any new processes; it's just easiest to think of it this way.
> Imagine
> your program being forked into two programs:  one program that continues
> to run
> until longjmp() is called and another that sits and waits at your setjmp()
> call
> for the other program to call longjmp().
>
> Basically it's a glorified (?) label/goto.  longjmp() is able to pass a
> single
> integer value back to setjmp() for error-reporting purposes.  Much like
> the
> fork() call, setjmp() returns 0 to continue normal execution upon first
> call,
> but will return the integer parameter passed to longjmp() if longjmp() was
> called at any time.  setjmp() simply places a marker on the location of
> where
> the function was called and longjmp() jumps back to that marker.
>
> Here's some example code (written in C, but the concept is the same):
>
> : #include <setjmp.h>
> :
> : jmp_buf error_context;
> :
> : int main() {
> :   int errval;
> :   printf("initial setjmp() call\n");
> :   errval = setjmp(error_context);
> :   printf("return from setjmp()\n");
> :   if (errval == 0) {
> :     // This is the initial call without an error.
> :
> :     printf("generating error\n");
> :     // Now let's generate an "error" by calling longjmp()...
> :     longjmp(error_context, 1);
> :
> :   } else {
> :     // Execution comes here after the longjmp(). Do you see?
> :     // The call to longjmp() effectively returns program state to back
> when
> :     // the setjmp() was called and forces it to return the value passed
> to
> longjmp(),
> :     // in this case: 1.
> :     printf("errval = %d\n", errval);
> :   }
> : }
>
> This code should produce the following output:
>
> : initial setjmp() call
> : return from setjmp()
> : generating error
> : return from setjmp()
> : errval = 1
>
> I just recently used the sigsetjmp() / siglongjmp() variants of the
> functions
> for signal handling under Linux.  When the system calls a signal handler,
> you
> have very limited functionality; so calling siglongjmp() from a signal
> handler
> will get you back within your program context.  This is useful in
> detecting
> horrible things like SIGSEGV (seg faults) and SIGFPE (floating point
> errors) so
> you can recover from them without much damage!
>
> Hope that helps -
>
> Regards,
> James Dunne