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

[someone]

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.

 

[Karthik]

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.

 

[Régis Troadec]

"someone" <[email protected]> a écrit dans le message de

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

 

[Peter Nilsson]

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.

 

[Chris Torek]

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

 

[SM Ryan]

(e-mail address removed) (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.