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

[Keith Thompson]

Richard Heathfield <rj*@see.sig.in validwrites:
[...]

Remember that this subthread was prompted by someone who suggested it's a
waste of time to check malloc's return value at all! Such people never ever
run out of memory, no matter how many Gigabytes of emergency reserve they
allocate. Their programs crash randomly sometimes for no apparent reason,
but at least they never run out of memory!

But the person who made this statement presented, as an alternative to
checking malloc's return value, a wrapper function that checks
malloc's return value. (Actually he presented a URL for such a
function.) Some posters here have advocated simply ignoring malloc()
failures; the poster in this thread (sorry, I don't remember who it
was) did not.

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

[Keith Thompson]

Eric Sosman <es*****@acm-dot-org.invalidwrit es:

Keith Thompson wrote:

>Eric Sosman <es*****@acm-dot-org.invalidwrit es:

[...]

>> A fairly common strategy is to malloc() a good-sized
chunk of memory "for emergency use only," sometime during
program initialization when memory is probably plentiful.
If malloc() fails later on, you free() the emergency stash
to provide enough memory for the graceful-shutdown code to
subsist on.

The cost of this is that you can run out of memory in cases where
there would have been enough if you hadn't allocated the emergency
stash.

True. Sometimes the canary dies even though the air in
the mine is still just barely breathable.

Right. But a more apt analogy here is that you bring a *really big*
canary into the mine with you. If the miners start to have trouble
breathing, you kill the canary and release the oxygen from its
bloodstream into the air, giving the miners enough time to exit
gracefully. (Ok, maybe it's just an inflatable plastic canary.) If
the miners were just about to leave anyway, bringing the canary was a
waste of time -- just as any insurance policy that doesn't pay off is
a waste of money. (Life insurance is a really bad deal if you happen
to be immortal.)

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

Keith Thompson wrote:

>

.... snip ...

waste of time -- just as any insurance policy that doesn't pay off
is a waste of money. (Life insurance is a really bad deal if you
happen to be immortal.)

Now I know why I haven't had any for the past 20 years :-) (Apart
from the Social Security death 'benefit').

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

[Richard Bos]

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

On Sat, 09 Dec 2006 16:42:14 +0000, Richard Heathfield wrote:

Roland Pibinger said:
<snip>

It hardly makes sense to check the return value of malloc.

It certainly doesn't make sense not to!

And what is your program supposed to do when memory is exhausted?

Depends entirely on the situation. If your word processor asks for a
large amount of memory to paste a graphic, and it doesn't get it,
putting up a message saying "sorry, no memory for graphic" is a lot more
civilised than just bombing out of the entire document. Even in the
worst case, putting up a meaningful message and exiting gracefully is
always better than crashing and burning.

Richard

[Richard Bos]

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

Richard

[Richard Heathfield]

Keith Thompson said:

Richard Heathfield <rj*@see.sig.in validwrites:
[...]

>Remember that this subthread was prompted by someone who suggested it's a
waste of time to check malloc's return value at all! Such people never
ever run out of memory, no matter how many Gigabytes of emergency reserve
they allocate. Their programs crash randomly sometimes for no apparent
reason, but at least they never run out of memory!

But the person who made this statement presented, as an alternative to
checking malloc's return value, a wrapper function that checks
malloc's return value.

He did? Oh, so he did. My apologies to Mr Pilinger. Nevertheless, whilst
"detect and die" does at least beat "ignore and hope", it remains a
neophyte solution - acceptable from, say, a first-year student. I'd expect
better from a second-year.

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

[Richard Bos]

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

On Sat, 09 Dec 2006 17:50:09 +0000, Richard Heathfield wrote:

Roland Pibinger said:

And what is your program supposed to do when memory is exhausted?

This is documented in the literature, and has been discussed on this
newsgroup a number of times before. See, for example:

<3D************ ***@eton.powern et.co.uk>

Those are mostly hints how to reduce the dynamic memory consumption of
a program but don't answer the question. OOM usually means that you
must terminate the application. The simplest way is a xmalloc-like
function. If enough context is available some cleanup can be done
before.

The problem with xmalloc()-like functions is that they crash anyway;
they just crash with a predictable message. This _may_ be good enough,
but IMO not nearly as often as I see it done in the wild.

Richard

[Richard Bos]

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

Roland Pibinger wrote:

Not all resources are equal and need equal treatment. It hardly makes
sense to check the return value of malloc. Just use a xmalloc function
which can be found in many variants on the internet (e.g.
http://www.tug.org/tex-archive/dviwa...2xx/xmalloc.c).

Well, it's so simple that most programmers will write their own
versions of it, if need be. The code seems to use the old style
function definition and uses unsigned instead of size_t, which isn't
the way it's done now. And calling exit() with a random value is not
portable. It's better to use EXIT_FAILURE.

Not to mention that the particular random value used in this xmalloc is,
erm, rather silly, given the comment above. Don't _all_ odd values mean
some kind of success on VMS?

Richard

[slebetman]

Bill Reid wrote:

Richard Heathfield <rj*@see.sig.in validwrote in message
news:fr******** *************** *******@bt.com. ..

MQ said:

Bill Reid wrote:
>
>For more complex functions, you'll quite often have contigent
>dependancies for each resource acquisition that don't fit neatly into
>the "nest", and the overhead of the function calling mechanism
>means that functions are not infinitely or always a "fabulous
>mechanism" for something as silly as "keeping the indent
>level down" (unless you like your "C" code to run as slow
>as "Java"!).
>
These are my greatest concerns, as I am writing file system driver code
that needs to be fast efficient.

Rule 1: if it doesn't work, it doesn't matter how fast it is.
Rule 2: it is easier to make a correct program fast than it is to make a
fast program correct.
Rule 3: it is easier to make a readable program correct than it is to make

a

correct program readable.

I think these are actually the three rules for pontificating about
programming instead of actually programming...y ears ago I read
the REAL rules for writing "correct" "fast" and "efficient" code, and
of course, as everybody who's not just pontificating knows,
it boils down to one general rule: pick the two you really want, because
a lot of times you CAN'T have all three...

And that's before we get anywhere near the Two Rules of

Micro-Optimisation.

For completeness, these are:

Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.

I certainly wasn't talking about anything like "micro-optimization".
I'm talking about great big gobs of "MACRO-optimization", like
slowing down or speeding up what was virtually the IDENTICAL
code by a factor of up to ten-fold (I could make the same program run
in either two seconds or 20 seconds)...

On a lot of modern CPUs the difference between a function call and a
jump (as in generated by switch or if) is nowhere near ten-fold when
compiled with an properly optimising compiler. One fold at most (note
that one-fold is ten times slower) or more typically up to 4 times
slower. Indeed on at least two architectures I code for, a function
call (if not recursive) compiles to execute in exactly the same number
of CPU cycles as a regular jump/branch.

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.

Of course, if you're programming for an architecture as archaic and
register-starved as the Pentium then function call overhead can be an
issue. Even so, improvements have been made to x86-64 which makes the
function call overhead for x86-64 even less than before.

[Roland Pibinger]

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.

Best wishes,
Roland Pibinger