• imr1984 (3/3) Jun 01 2005 Has anyone written a library for the setjmp functions?
• zwang (3/9) Jun 01 2005 I badly need the setjmp/longjmp functions... for writing obfuscated D co...
• Andrew Fedoniouk (7/11) Jun 01 2005 setjump allows to restore state of execution environment including
• Tony (13/27) Jun 01 2005 back
• James Dunne (57/67) Jun 02 2005 Having just recently discovered the magic of setjmp/longjmp function cal...
• Andrew Fedoniouk (6/98) Jun 02 2005

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

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.

"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?

"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


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

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

"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