Cleanup patterns

[MQ]

Hi all

I am just wondering how most people implement cleanup in C functions.
In particular, if the function opens a number of resources, these need
to be released properly should an error occur at any point in the
function (as well as at the end if successful). C++ has exceptions,
the only way I can see to do this neatly in C is to use goto
statements. Is my method of implementing cleanup good, or are their
better ways. Here is an example, which uses the global errno to store
the error.

#define CLEANUP(err) ({errno = (err); goto cleanup})

int example_functio n()
{
SOMETYPE * a,b,c;
errno = 0;

if(!(a = malloc(sizeof(a ))))
CLEANUP(ENOMEM) ;

if(!(b = malloc(sizeof(b ))))
CLEANUP(ENOMEM) ;

if(!(c = malloc(sizeof(c ))))
CLEANUP(ENOMEM) ;

/* do something here */

cleanup:
if(a)
free(a);
if(b);
free(b);
if(c)
free(c);
if(errno)
return -1;
return 0;
}

[Ian Collins]

Bill Reid wrote:

>
This is not exactly an academic exercise for me, since a lot of the
code I work with takes several HOURS to run on a Pentium-class
machine, and I have to run it EVERY day.

Maybe it's time for a 64 bit upgrade!

--
Ian Collins.

[Keith Thompson]

rp*****@yahoo.c om (Roland Pibinger) writes:

On Mon, 11 Dec 2006 07:41:06 GMT, Richard Bos wrote:

>>The problem with xmalloc()-like functions is that they crash anyway;
they just crash with a predictable message.

They don't crash the program, they call exit (which also calls
atexit).

>>This _may_ be good enough,
but IMO not nearly as often as I see it done in the wild.

In order to run your program primarily needs one resource, memory.

Along with a number of other resources.

When it runs out of memory (e.g. due to a memory leak) there is hardly
anything you can do except to (more or less) gracefully terminate the
program.

That's not always true; it depends on the application. Somebody
already posted an example of an interactive editor failing to allocate
enough memory to load an image; the proper response is to issue a
diagnostic and continue running, not to crash the program.

Not even that is always possible since some OS (IIRC, Linux)
never return NULL for malloc even when memory is exhausted.

That behavior is arguably non-conforming.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Keith Thompson said:

rp*****@yahoo.c om (Roland Pibinger) writes:

> Not even that is always possible since some OS (IIRC, Linux)
never return NULL for malloc even when memory is exhausted.

That behavior is arguably non-conforming.

I would have no doubt about that - it's non-conforming. What I would
question is the OP's claim that Linux over-commits. It is true that it can
be configured to over-commit, but certainly my installation is not
configured that way by default.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[santosh]

Keith Thompson wrote:

rp*****@yahoo.c om (Roland Pibinger) writes:

On Mon, 11 Dec 2006 07:41:06 GMT, Richard Bos wrote:

>The problem with xmalloc()-like functions is that they crash anyway;
they just crash with a predictable message.

They don't crash the program, they call exit (which also calls
atexit).

>This _may_ be good enough,
but IMO not nearly as often as I see it done in the wild.

In order to run your program primarily needs one resource, memory.

Along with a number of other resources.

When it runs out of memory (e.g. due to a memory leak) there is hardly
anything you can do except to (more or less) gracefully terminate the
program.

That's not always true; it depends on the application. Somebody
already posted an example of an interactive editor failing to allocate
enough memory to load an image; the proper response is to issue a
diagnostic and continue running, not to crash the program.

Not even that is always possible since some OS (IIRC, Linux)
never return NULL for malloc even when memory is exhausted.

That behavior is arguably non-conforming.

To what standard? Linux's behaviour is outside the scope of the C
standard. Nevertheless, by never returning NULL, even when memory is
not available, it does make the malloc() implementation non-conforming.

Actually since from within the standard C program you cannot find out
_if_ memory is available or not, malloc()'s behaviour under OSes like
Linux is not non-conforming. It's doing it's job correctly, it just so
happens that it's subverted by forces outside it's control, (and the
standard's.)

[Richard Heathfield]

santosh said:

Keith Thompson wrote:

>rp*****@yahoo.c om (Roland Pibinger) writes:

Not even that is always possible since some OS (IIRC, Linux)
never return NULL for malloc even when memory is exhausted.

That behavior is arguably non-conforming.

To what standard?

ISO/IEC 9899. Some people view the operating system as being part of the
implementation. This is a not unreasonable view, although it's a bit hard
on compiler-writers if they have no control over the behaviour of the OS on
their platform...

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[santosh]

Richard Heathfield wrote:

santosh said:

Keith Thompson wrote:

rp*****@yahoo.c om (Roland Pibinger) writes:

Not even that is always possible since some OS (IIRC, Linux)
never return NULL for malloc even when memory is exhausted.

That behavior is arguably non-conforming.

To what standard?

ISO/IEC 9899. Some people view the operating system as being part of the
implementation.

<snip>

Yes well, in that case we can add the hardware and the rest of the
physical universe as part of the implementation too.

:)

[Keith Thompson]

"santosh" <sa*********@gm ail.comwrites:

Richard Heathfield wrote:

>santosh said:

Keith Thompson wrote:
rp*****@yahoo.c om (Roland Pibinger) writes:

Not even that is always possible since some OS (IIRC, Linux)
never return NULL for malloc even when memory is exhausted.

That behavior is arguably non-conforming.

To what standard?

ISO/IEC 9899. Some people view the operating system as being part of the
implementation .

<snip>

Yes well, in that case we can add the hardware and the rest of the
physical universe as part of the implementation too.

:)

Yes.

An implementation that doesn't meet the requirements of the standard
is non-conforming. Having a good excuse for the non-conformance
doesn't make it conforming.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

Richard Bos wrote:

rp*****@yahoo.c om (Roland Pibinger) wrote:

>On Sat, 09 Dec 2006 12:47:38 -0500, CBFalconer wrote:

>>Consider a big sort where the
input mechanism collects records in a linked list until memory is
exhauseted, mergesorts the list, dumps it to a temporary file,
discards the list, and repeats, dumping to the next temporary
file. When the input is exhausted it mergest the set of
temporaries into an output file.

Isn't there an external mergesort?

Yes. But they're typically a lot slower than internal sorts, so you
don't use it until you _know_ that you need it. Hence the check on
malloc().

The relative slowness is because the external sort is primarily
dependant on the i/o processing. You can get remarkable
performance by minimizing that i/o. See Wirths "Algorithms + Data
Structures = Programs" for polyphase sort. Triggering virtual
memory operation will foul that up quite nicely.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[CBFalconer]

Roland Pibinger wrote:

On Mon, 11 Dec 2006 07:41:06 GMT, Richard Bos wrote:

>The problem with xmalloc()-like functions is that they crash
anyway; they just crash with a predictable message.

They don't crash the program, they call exit (which also calls
atexit).

>This _may_ be good enough,
but IMO not nearly as often as I see it done in the wild.

In order to run your program primarily needs one resource, memory.
When it runs out of memory (e.g. due to a memory leak) there is
hardly anything you can do except to (more or less) gracefully
terminate the program. Not even that is always possible since some
OS (IIRC, Linux) never return NULL for malloc even when memory is
exhausted.

Not so. I gave an example (external sort) upthread. To misquote
Dan Pop, engage brain before aborting.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[CBFalconer]

santosh wrote:

Keith Thompson wrote:

>rp*****@yahoo.c om (Roland Pibinger) writes:

.... snip ...

>>

>>Not even that is always possible since some OS (IIRC, Linux)
never return NULL for malloc even when memory is exhausted.

That behavior is arguably non-conforming.

To what standard? Linux's behaviour is outside the scope of the C
standard. Nevertheless, by never returning NULL, even when memory
is not available, it does make the malloc() implementation
non-conforming.

Actually since from within the standard C program you cannot find
out _if_ memory is available or not, malloc()'s behaviour under
OSes like Linux is not non-conforming. It's doing it's job
correctly, it just so happens that it's subverted by forces
outside it's control, (and the standard's.)

Again, not necessarily. There is no speed requirement, so an OS
can simply postpone program execution until the memory is actually
available. Implementing this could run into the deadly embrace
problem.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>