468,791 Members | 1,781 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,791 developers. It's quick & easy.

help: why setjmp/longjmp take STRUCT jmp_buf as parameter, not a pointer?

I have *thought* that setjmp/longjmp() should take a pointer to
jmp_buf. And the calling function should hold the actual struct data.
But ... I trid on both Win32 and Linux, it seems that
setjmp/longjmp() are taking stuct:

c:\> dmc sj.c (Digital Mars Compiler Version 8.38n)
link sj,,,user32+kernel32/noi;
c:\> sj.exe
sizeof(jmp_buf) = 64
----------------------------------------------------------------- sj.c
-----
#include <setjmp.h>
#include <stdio.h>

int main()
{
printf("sizeof(jmp_buf) = %d\n", sizeof(jmp_buf));
return 0;
}
----------------------------------------------------------------- sj.c
-----

And on Linux:

[d] ./sj
sizeof(jmp_buf) = 156

I'm totally confused. The jmp_buf is used to store the program state
info in setjmp(), and the info will be used again when longjmp is
called.

However in C, struct is pass-by-copy; so the calling function's
jmp_buf will not be modified, because setjmp() can only modify it's
own copy of jmp_buf. Then where is the info stored, and how longjmp()
can use the saved info to jump back?

What's the magic behind, or I miss something?

Can you try my example? and can you give an explanation?

Thanks.
Nov 14 '05 #1
6 4538
someone wrote:

What's the magic behind, or I miss something?

It is simple as that. It is implementation-dependent. And I dont
think the C standard defines this.
For example, for me on Win32 i got it to be 64 ( I used MS VC++ IDE
,cl compiler )
On Solaris, I got 48 ( gcc ).

If you can add more info. about this, it would be helpful.

--
Karthik
Humans please 'removeme_' for my real email.
Nov 14 '05 #2

"someone" <so******@yahoo.com> a écrit dans le message de
news:eb**************************@posting.google.c om...

Hi,
I have *thought* that setjmp/longjmp() should take a pointer to
jmp_buf. And the calling function should hold the actual struct data.
But ... I trid on both Win32 and Linux, it seems that
setjmp/longjmp() are taking stuct:
setjmp/longjmp() are taking an argument of type jmp_buf, not a structure or
pointer to structure.

[snipped]

I'm totally confused. The jmp_buf is used to store the program state
info in setjmp(), and the info will be used again when longjmp is
called.

However in C, struct is pass-by-copy; so the calling function's
jmp_buf will not be modified, because setjmp() can only modify it's
own copy of jmp_buf. Then where is the info stored, and how longjmp()
can use the saved info to jump back?

What's the magic behind, or I miss something?


There is no magic behind, jmp_buf is in fact an array type.

Regis
Nov 14 '05 #3
"someone" <so******@yahoo.com> wrote in message
news:eb**************************@posting.google.c om...
I have *thought* that setjmp/longjmp() should take a pointer to
jmp_buf. And the calling function should hold the actual struct data.
But ... I trid on both Win32 and Linux, it seems that
setjmp/longjmp() are taking stuct:

c:\> dmc sj.c (Digital Mars Compiler Version 8.38n)
link sj,,,user32+kernel32/noi;
c:\> sj.exe
sizeof(jmp_buf) = 64
....
I'm totally confused. The jmp_buf is used to store the program state
info in setjmp(), and the info will be used again when longjmp is
called.

However in C, struct is pass-by-copy; so the calling function's
jmp_buf will not be modified, because setjmp() can only modify it's
own copy of jmp_buf. Then where is the info stored, and how longjmp()
can use the saved info to jump back?

What's the magic behind, or I miss something?


jmp_buf is an array, not a struct.

--
Peter
Nov 14 '05 #4
In article <news:40******@news.rivernet.com.au>
Peter Nilsson <ai***@acay.com.au> writes:
jmp_buf is an array, not a struct.


Indeed. It may, of course, be a type-alias for an array of one
element, whose element-type is a structure type. This is the case
for every setjmp() implementation I have written (which is not
very many; mostly I have to work within someone else's initial
implementation).

In other words:

typedef struct __jmp_buf jmp_buf[1];
struct __jmp_buf { ... contents ... };

is a valid implementation, but changing the first line to:

typedef struct __jmp_buf jmp_buf;

is not, even if the implementation happens to pass structures by
reference internally. Why? Becuase the C Standards say so:

7.10 Nonlocal jumps <setjmp.h>

[#1] The header <setjmp.h> defines the macro setjmp, and
declares one function and one type, for bypassing the normal
function call and return discipline.191

[#2] The type declared is

jmp_buf

which is an array type suitable for holding the information
needed to restore a calling environment. ...

The C standard says "this is an array type" so it had better be an
array type. An implementation can cheat if and only if the effect
of cheating is invisible, and array types have visible characteristics.
For instance, "sizeof instance" is usually different from "sizeof
(instance + 0)", and applying "+ 0" to an array object is always
valid:

#include <setjmp.h>
#include <stdio.h>

int main(void) {
jmp_buf x;
printf("sizes: %lu %lu\n", (unsigned long)sizeof x,
(unsigned long) sizeof(x + 0));
return 0;
}

This *must* compile and will virtually always print two different
numbers (in rare cases you might actually get "8 8" today). The
array object "x" has as its size the number of bytes in the entire
array, while adding zero causes the array object to undergo the
transition prescribed by The Rule about arrays and pointers in C,
so that sizeof (x + 0) is the number of bytes in a pointer to the
first element of the array. The second number is usually 4 or 8
today, while the first is often at least 12 and almost always at
least 8 (to hold stack and frame pointers, plus another 4 or more
for signal information in POSIX systems).
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 14 '05 #5
so******@yahoo.com (someone) wrote:
# I have *thought* that setjmp/longjmp() should take a pointer to
# jmp_buf. And the calling function should hold the actual struct data.
# But ... I trid on both Win32 and Linux, it seems that
# setjmp/longjmp() are taking stuct:

setjmp/longjmp are magic, like stdargs. It might make sense as C code, it
might not: the source code that is there might be intecepted and handled
differently by the compiler.

It's like an eggroll. You eat it whole and don't worry about the individual
ingredients.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
GERBILS
GERBILS
GERBILS
Nov 14 '05 #6
so******@yahoo.com (someone) wrote:
# I have *thought* that setjmp/longjmp() should take a pointer to
# jmp_buf. And the calling function should hold the actual struct data.
# But ... I trid on both Win32 and Linux, it seems that
# setjmp/longjmp() are taking stuct:

setjmp/longjmp are magic, like stdargs. It might make sense as C code, it
might not: the source code that is there might be intecepted and handled
differently by the compiler.

It's like an eggroll. You eat it whole and don't worry about the individual
ingredients.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
GERBILS
GERBILS
GERBILS
Nov 14 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

18 posts views Thread by Peter Smithson | last post: by
20 posts views Thread by JS | last post: by
2 posts views Thread by JS | last post: by
8 posts views Thread by Zheng Da | last post: by
4 posts views Thread by Sreekanth | last post: by
15 posts views Thread by rover8898 | last post: by
3 posts views Thread by no_click_there | last post: by
reply views Thread by sh.vipin | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.