is jmp_buf a bona fide object?
luser- -droog
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.
--
James Kuyper
Kenny McCormack
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.
--
Eric Sosman
eso...@ieee-dot-org.invalid
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
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.
Kenneth Brody
> On 3/19/2011 4:13 AM, luser- -droog wrote:
>> 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.
--
Kenneth Brody
Eric Sosman
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.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Kenny McCormack
Eric Sosman <eso...@ieee-dot-org.invalid> wrote:
...
>> 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,
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.
--
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...