error handlling in recursive function

[pereges]

How to to go about this ? Suppose a malloc inside a recursive function
has failed and you want to set the error flag and return it to the
calling function(the one which called the recursive function in the
first place)

[David Resnick]

On May 30, 9:22 am, pereges <[e-mail]:

How to to go about this ? Suppose a malloc inside a recursive function
has failed and you want to set the error flag and return it to the
calling function(the one which called the recursive function in the
first place)

Options seem to be:

1) Propagate the flag back through the stack of recursive functions,
checking for it at each invocation. This is the best way if you need
to, say, release resources in each invocation of the recursive
function, which seems possible given that you are mallocing in the
recursion.

2) Use setjmp (before entering recursion) and longjmp to hop back on
error.

n.b. this is a case where exception throwing is nice, as with minimal
fuss it gets you back to the level that wants to handle the error
cleaning up all in between. But as we're in C, not an option

-David

[Jens Thoms Toerring]

David Resnick <ln********@gmail.comwrote:

On May 30, 9:22 am, pereges <[e-mail]:

How to to go about this ? Suppose a malloc inside a recursive function
has failed and you want to set the error flag and return it to the
calling function(the one which called the recursive function in the
first place)

Options seem to be:

1) Propagate the flag back through the stack of recursive functions,
checking for it at each invocation. This is the best way if you need
to, say, release resources in each invocation of the recursive
function, which seems possible given that you are mallocing in the
recursion.

2) Use setjmp (before entering recursion) and longjmp to hop back on
error.

A third option might be to have a global variable (at file scope)
that gets set if an error occurs. Ok, global variables are EVIL,
but this may be one of the cases where their use can simplify
things a bit...
Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\__________________________ http://toerring.de

[CBFalconer]

pereges wrote:

>
How to to go about this ? Suppose a malloc inside a recursive
function has failed and you want to set the error flag and return
it to the calling function(the one which called the recursive
function in the first place)

void *operationfails(...) {
int *p;

if (p = malloc(whatever)) {
/* do your thing on it */
}
return p; /* which is NULL for failure */
}

for example.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[David Resnick]

On May 30, 11:46 am, [e-mail] (Jens Thoms Toerring) wrote:

David Resnick <[e-mail]:

On May 30, 9:22 am, pereges <[e-mail]:

How to to go about this ? Suppose a malloc inside a recursive function
has failed and you want to set the error flag and return it to the
calling function(the one which called the recursive function in the
first place)

Options seem to be:
1) Propagate the flag back through the stack of recursive functions,
checking for it at each invocation. This is the best way if you need
to, say, release resources in each invocation of the recursive
function, which seems possible given that you are mallocing in the
recursion.
2) Use setjmp (before entering recursion) and longjmp to hop back on
error.

A third option might be to have a global variable (at file scope)
that gets set if an error occurs. Ok, global variables are EVIL,
but this may be one of the cases where their use can simplify
things a bit...

Sure, and a fourth is to pass down a pointer to a variable to use for
error reporting. I gave the answer I did because I interpreted his
question as being also how to reasonably unwind the stack of recursive
invocations when hitting an error condition...

-David

[user923005]

On May 30, 10:17*am, David Resnick <[e-mail]:

On May 30, 11:46 am, [e-mail] (Jens Thoms Toerring) wrote:

David Resnick <[e-mail]:

On May 30, 9:22 am, pereges <[e-mail]:
How to to go about this ? Suppose a malloc inside a recursive function
has failed and you want to set the error flag and return it to the
calling function(the one which called the recursive function in the
first place)
Options seem to be:
1) Propagate the flag back through the stack of recursive functions,
checking for it at each invocation. *This is the best way if you need
to, say, release resources in each invocation of the recursive
function, which seems possible given that you are mallocing in the
recursion.
2) Use setjmp (before entering recursion) and longjmp to hop back on
error.

A third option might be to have a global variable (at file scope)
that gets set if an error occurs. Ok, global variables are EVIL,
but this may be one of the cases where their use can simplify
things a bit...

Sure, and a fourth is to pass down a pointer to a variable to use for
error reporting. *I gave the answer I did because I interpreted his
question as being also how to reasonably unwind the stack of recursive
invocations when hitting an error condition...

Yet another one is to use signal()/raise(). E.g.:
http://publications.gbdirect.co.uk/c..._handling.html

[Walter Roberson]

In article <19**********************************@x35g2000hsb. googlegroups.com>,
user923005 <dc*****@connx.comwrote:

>On May 30, 10:17=A0am, David Resnick <[e-mail]:

>Sure, and a fourth is to pass down a pointer to a variable to use for
error reporting.

>Yet another one is to use signal()/raise().

If the routine so invoked does not terminate with longjump
(and longjump was already proffered earlier in the list) then
when the routine returns, execution will resume with the return
of raise() (which will have a value of 0 if successful, non-zero
otherwise.)

signal()/raise() does have the advantage that the invoked routine
is able to access library functions, and is able to access static storage
that is not volatile sig_atomic_t (undefined behaviour if the
invocation of the signal'd routine does not come from raise()).
Effectively, signal()/raise() becomes a method for storing a hidden
global pointer to a subroutine that gets called when raise() is used...
nothing you couldn't easily duplicate. Hmmm, I bet there has already
been an IOCC entry (or five) that relied upon this...
--
"I want to be remembered as the guy who gave his all whenever
he was on the field." -- Walter Payton

[Antoninus Twink]

On 30 May 2008 at 19:27, Walter Roberson wrote:

If the routine so invoked does not terminate with longjump

What's longjump?

(Think I'll make it as a pedant? :) )

[Walter Roberson]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>On 30 May 2008 at 19:27, Walter Roberson wrote:

>If the routine so invoked does not terminate with longjump

>What's longjump?

'jmp' was considered to be a machine-specific instruction, so in
TC9 longjmp will be deprecated and the more general longjump substituted
instead. ;-)

>(Think I'll make it as a pedant? :) )

Always hoped that I'd be a pedant
Knew that I would make it if I tried (If I tried)
Then when we retire we can write the corrigenda
So they'll still talk about us when we've died

(With apologies to Mr. Webber)
--
"It's a hard life sometimes and the biggest temptation is to let
how hard it is be an excuse to weaken." -- Walter Dean Myers

[Malcolm McLean]

"David Resnick" <ln********@gmail.comwrote in message

>A third option might be to have a global variable (at file scope)
that gets set if an error occurs. Ok, global variables are EVIL,
but this may be one of the cases where their use can simplify
things a bit...

Sure, and a fourth is to pass down a pointer to a variable to use for
error reporting. I gave the answer I did because I interpreted his
question as being also how to reasonably unwind the stack of recursive
invocations when hitting an error condition...

MiniBasic has exactly this problem.
The solution is to have a sticky error. So once one error is set, all
subsequent errors are suppressed. So the rest of the code can chug on,
returning in its own good time - obviously you have to be a bit careful not
to write to potentially null pointers and so on, but there is no reason to
stop expression parsing jsut because a string wasn't allocated somewhere.

PS website contains important programming and scientific information.
Someone please check availability for me.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Chad]

On May 30, 12:27 pm, [e-mail] (Walter Roberson)
wrote:

In article <[e-mail]>,

user923005 <[e-mail]:

On May 30, 10:17=A0am, David Resnick <[e-mail]:

Sure, and a fourth is to pass down a pointer to a variable to use for
error reporting.

Yet another one is to use signal()/raise().

If the routine so invoked does not terminate with longjump
(and longjump was already proffered earlier in the list) then
when the routine returns, execution will resume with the return
of raise() (which will have a value of 0 if successful, non-zero
otherwise.)

signal()/raise() does have the advantage that the invoked routine
is able to access library functions,

I don't get what you mean when you say "signal()/raise() does have the
advantage that the invoked routine is able to access library
functions, "

Can you give an example of this?

Chad