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.

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.

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

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.

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

On Mar 19, 3:13=A0am, 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.

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

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

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