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)

On May 30, 9:22 am, pereges <Brol...@gmail.com> 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)

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

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 <lndresnick@gmail.com> wrote:
> On May 30, 9:22 am, pereges <Brol...@gmail.com> 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)

> 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 ___ jt@toerring.de
\__________________________ http://toerring.de

On May 30, 11:46 am, j...@toerring.de (Jens Thoms Toerring) wrote:
> David Resnick <lndresn...@gmail.com> wrote:
> > On May 30, 9:22 am, pereges <Brol...@gmail.com> 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)
> > 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

On May 30, 10:17am, David Resnick <lndresn...@gmail.com> wrote:
> On May 30, 11:46 am, j...@toerring.de (Jens Thoms Toerring) wrote:
>
>
>
>
>
> > David Resnick <lndresn...@gmail.com> wrote:
> > > On May 30, 9:22 am, pereges <Brol...@gmail.com> 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)
> > > 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

In article <19b77d08-9400-4bcc-b5ef-112545eda14f@x35g2000hsb.googlegroups.com>,
user923005 <dcorbit@connx.com> wrote:
>On May 30, 10:17=A0am, David Resnick <lndresn...@gmail.com> wrote:

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

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? )