problem with setjmp

C

candy

hi all,

Consider the following C code:




void funct(){
}


int main(){
int x;
x=funct;
printf("%x\n",x);
return 0;
}

It prints the address of the function funct().It means that
the function funct() is in the process stack even before it is
called.So,it should be safe to call setjmp in the function
funct() in the following way:


jmp_buf env;

int funct(){

if(setjmp(env)==1)
printf("called by longjmp\n");
return 0;
}

int main(void){

funct();
longjmp(env,1);
return 0;
}

On execution,the above program crashes.Can anybody please tell me
that what is the problem.

Thanks.
 
M

Merrill & Michele

candy said:
hi all,

Consider the following C code:




void funct(){
}


int main(){
int x;
x=funct;
printf("%x\n",x);
return 0;
}

It prints the address of the function funct().It means that
the function funct() is in the process stack even before it is
called.So,it should be safe to call setjmp in the function
funct() in the following way:


jmp_buf env;

int funct(){

if(setjmp(env)==1)
printf("called by longjmp\n");
return 0;
}

int main(void){

funct();
longjmp(env,1);
return 0;
}

On execution,the above program crashes.Can anybody please tell me
that what is the problem.

Thanks.

K&R2 table 5-1 addresses one of your problems, I believe. MPJ
 
J

Jack Klein

hi all,

Consider the following C code:




void funct(){
}


int main(){
int x;
x=funct;

This is both a constraint violation and produces undefined behavior.
If you have a compiler that accepts this, either it is actually not a
C compiler or it is not being invoked as a conforming C compiler.
printf("%x\n",x);

More undefined behavior here, the "%x" conversion specifier to the
printf() family of functions requires an unsigned int parameter, not a
signed int.
return 0;
}

It prints the address of the function funct().It means that

Whatever it does or does not do is not specified by the C language due
to the undefined behavior.
the function funct() is in the process stack even before it is

What exactly do you think a "process stack" is? I have never heard of
the term before.
called.So,it should be safe to call setjmp in the function
funct() in the following way:

Why do you think it is safe? This is not how the setjmp() and
longjmp() functions are defined to work.
jmp_buf env;

int funct(){

if(setjmp(env)==1)
printf("called by longjmp\n");
return 0;
}

int main(void){

funct();
longjmp(env,1);
return 0;
}

On execution,the above program crashes.Can anybody please tell me
that what is the problem.

The problem is that you need to get a good book or online reference on
C and read how setjmp() and longjmp() work.

The function performing a longjmp() must be called directly or
indirectly by the function that performed the setjmp() on the buffer.
setjmp/longjmp only works in one direction in a function call tree.
You are trying to go in the opposite direction, and it does not and
will not ever work that way.
 
C

Chris Torek

Consider the following C code:

void funct(){
}

int main(){
int x;
x=funct;
printf("%x\n",x);
return 0;
}

It prints the address of the function funct().

No; it does not even compile:

% strictcc t.c
t.c: In function `main':
t.c:6: error: assignment makes integer from pointer without a cast
t.c:7: error: implicit declaration of function `printf'
%
[no executable produced]

On the IA64, for instance, funct has a 64-bit address, but x is
only 32 bits long. What happens when you put 64 bits into a 32-bit
holder?
It means that the function funct() is in the process stack even
before it is called.

No. Even where there is a "process stack", and even where function
addresses happen to fit in "int"s (e.g., IA32), there is no activation
record for funct() on that stack at that point.
So,it should be safe to call setjmp in the function funct() in the
following way:

jmp_buf env;

int funct(){

if(setjmp(env)==1)
printf("called by longjmp\n");
return 0;
}

int main(void){

funct();
longjmp(env,1);
return 0;
}

On execution,the above program crashes.Can anybody please tell me
that what is the problem.

The call to longjmp() attempts to jump into a function activation
that has already returned. This is not allowed in Standard C; the
effect is undefined. You are lucky that it crashed, rather than
doing some sort of by pretending to work.

(Some people sometimes attempt to [ab]use longjmp() to implement
thread context switchers. Whether this works is up to the
implementation: some implementations actually unwind the stack
inside longjmp(), looking for the corresponding setjmp(), and since
different threads have separate stacks, the unwound stack eventually
reaches its top and the program simply aborts or crashes. In
general, you are better off writing your thread-context-switch code
in machine-specific assembly-language -- you usually need some
anyway to save registers, for instance.)
 
A

alice

Jack Klein said:
On 28 Nov 2004 08:37:01 -0800, (e-mail address removed) (candy) wrote in
comp.lang.c:


The problem is that you need to get a good book or online reference on
C and read how setjmp() and longjmp() work.
Ok,can you please tell me such a good link or an online reference where I can
read about setjmp.K&R has a very brief introduction of setjmp and longjmp
and the same is the case with the man pages.

Thanks in advance,
Alice
 
D

Dan Pop

In said:
Ok,can you please tell me such a good link or an online reference where I can
read about setjmp.K&R has a very brief introduction of setjmp and longjmp
and the same is the case with the man pages.

The description from K&R2 might be short (less than half a page), but it
tells you everything you need to know. Pay attention to each and every
detail, even reputable authors like H&S have gotten one thing wrong in
their book.

Dan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top