www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - setjmp

reply imr1984 <imr1984_member pathlink.com> writes:
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).
Jun 01 2005
next sibling parent zwang <nehzgnaw gmail.com> writes:
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.
Jun 01 2005
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"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?
Jun 01 2005
parent reply "Tony" <talktotony email.com> writes:
"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


 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
Jun 01 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
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
Jun 02 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"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 

Jun 02 2005