is jmp_buf a bona fide object?

[luser- -droog]

For my project I need to make the entire program recursive
up to a maximum pre-defined limit (15), but it uses setjmp/
longjmp to recover from errors. Can I treat a jmp_buf like
an object? Can I assign variables of type jmp_buf to other
variables of the same type? More to the points, can I make
an array of them to hold outer scopes while the innermost
instance uses setjmp/longjmp to jump from the error
function back to the main loop?
I thought about copying it to a local variable and restoring
after the recursive call; but since the spec gives a limit,
it seems better to make use of it.

 

[Nobody]

For my project I need to make the entire program recursive
up to a maximum pre-defined limit (15), but it uses setjmp/
longjmp to recover from errors. Can I treat a jmp_buf like
an object? Can I assign variables of type jmp_buf to other
variables of the same type? More to the points, can I make
an array of them to hold outer scopes while the innermost
instance uses setjmp/longjmp to jump from the error
function back to the main loop?

7.13 Nonlocal jumps <setjmp.h>

...

[#2] The type declared is

jmp_buf

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

So: no, you can't assign one variable of type jmp_buf to another. OTOH,
I don't know of any reason why having an array of jmp_buf's would be an
issue.

 

[James Kuyper]

For my project I need to make the entire program recursive
up to a maximum pre-defined limit (15), but it uses setjmp/
longjmp to recover from errors. Can I treat a jmp_buf like
an object? Can I assign variables of type jmp_buf to other
variables of the same type?

Since jmp_buf is described as an array type, you cannot assign to it.
However, It should be perfectly feasible to memcpy() it.

 

[Kenny McCormack]

Since jmp_buf is described as an array type, you cannot assign to it.
However, It should be perfectly feasible to memcpy() it.

Or, of course, wrap it in a struct. Then you can assign to/from it.

--
Windows 95 n. (Win-doze): A 32 bit extension to a 16 bit user interface for
an 8 bit operating system based on a 4 bit architecture from a 2 bit company
that can't stand 1 bit of competition.

Modern day upgrade --> Windows XP Professional x64: Windows is now a 64 bit
tweak of a 32 bit extension to a 16 bit user interface for an 8 bit
operating system based on a 4 bit architecture from a 2 bit company that
can't stand 1 bit of competition.

 

[Eric Sosman]

For my project I need to make the entire program recursive
up to a maximum pre-defined limit (15), but it uses setjmp/
longjmp to recover from errors. Can I treat a jmp_buf like
an object?
Yes.

Can I assign variables of type jmp_buf to other
variables of the same type?
No.

More to the points, can I make
an array of them to hold outer scopes while the innermost
instance uses setjmp/longjmp to jump from the error
function back to the main loop?

Yes.

Y'know, a few moments with a reference book or with the
Standard itself would have answered all these questions *and*
explained the reasons. Even a few moments experimenting with
a compiler would have helped.

 

[luser- -droog]

For my project I need to make the entire program recursive
up to a maximum pre-defined limit (15), but it uses setjmp/
longjmp to recover from errors. Can I treat a jmp_buf like
an object? ...

Thanks for all responses. It appears now that this whole issue
is a result of premature optimization. I had moved the setjmp
call to just before the main loop. If I put it back into the
loop, a single jmp_buf should suffice even for recursive
invocations.

 

[Eric Sosman]

For my project I need to make the entire program recursive
up to a maximum pre-defined limit (15), but it uses setjmp/
longjmp to recover from errors. Can I treat a jmp_buf like
an object?

[...]
Y'know, a few moments with a reference book or with the
Standard itself would have answered all these questions *and*
explained the reasons. Even a few moments experimenting with
a compiler would have helped.

To be fair, "a few moments experimenting with a compiler" is what leads
to code like "foo[x] = x++;". While certainly useful, it's not
necessarily good for answering "is this 'legal' and/or portable C" types
of questions.

Agreed: Experimenting with the compiler cannot provide a positive
assurance of conformity. However, it *can* provide a fairly reliable
negative signal. For example,

#include <setjmp.h>
int main(void) {
jmp_buf x, y;
x = y;
return 0;
}

.... would have answered one of the O.P.'s questions--with a diagnostic.

 

[Kenny McCormack]

To be fair, "a few moments experimenting with a compiler" is what leads
to code like "foo[x] = x++;". While certainly useful, it's not
necessarily good for answering "is this 'legal' and/or portable C" types
of questions.

Agreed: Experimenting with the compiler cannot provide a positive
assurance of conformity. However, it *can* provide a fairly reliable
negative signal. For example,[/QUOTE]

Not necessarily. He might conclude, correctly in some instances, that his
compiler was faulty (*). That's always a possibility.

(*) Or "non-conforming", which, in the language of this newsgroup, is the
same thing.