Asp Forum - is jmp_buf a bona fide object?

luserXtrog

3/19/2011 8:13:00 AM

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.

8 Answers

John Doe

3/19/2011 10:06:00 AM

On Sat, 19 Mar 2011 01:13:23 -0700, 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? 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

3/19/2011 11:00:00 AM

On 03/19/2011 04: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? 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

gazelle

3/19/2011 12:10:00 PM

In article <im22cd$ik7$1@news.eternal-september.org>,
James Kuyper <jameskuyper@verizon.net> wrote:
>On 03/19/2011 04: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? 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.

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

3/19/2011 1:13:00 PM

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?

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
esosman@ieee-dot-org.invalid

luserXtrog

3/20/2011 5:37:00 AM

On Mar 19, 3:13 am, luser- -droog <mijo...@yahoo.com> 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? ...

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

3/21/2011 5:18:00 PM

On 3/19/2011 9:13 AM, Eric Sosman wrote:
> 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

3/22/2011 12:49:00 AM

On 3/21/2011 1:18 PM, Kenneth Brody wrote:
> On 3/19/2011 9:13 AM, Eric Sosman wrote:
>> 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.

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
esosman@ieee-dot-org.invalid

gazelle

5/8/2011 1:14:00 PM

In article <im8rmo$n1s$1@news.eternal-september.org>,
Eric Sosman <esosman@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...

comp.lang.c

is jmp_buf a bona fide object?

luserXtrog

John Doe

James Kuyper

gazelle

Eric Sosman

luserXtrog

Kenneth Brody

Eric Sosman

gazelle

x Login to ForumsZone