Re: why no palloc() ("permanent alloc")?
- From: "Joachim Schmitz" <nospam.jojo@xxxxxxxxxxxxxxxxxx>
- Date: Sat, 19 Jul 2008 22:24:29 +0200
phil-news-nospam@xxxxxxxx wrote:
On Sat, 19 Jul 2008 19:36:26 +0200 Joachim Schmitz
<nospam.jojo@xxxxxxxxxxxxxxxxxx> wrote:
Bernie Ohls wrote:
I've spent a lot of time lately scrubbing my C code, using tools
like Valgrind on Linux and bcheck and libumem on Solaris which find
memory leaks, bad frees, etc. One annoyance I've seen in many of
these tools is that they list lots of spurious memory leaks.
When I say "spurious" I mean that technically they _are_ leaks, in
the sense that they're memory which was allocated and never freed.
But most of the time there are going to be some things you allocate
and never _want_ to free. Consider exporting an environment
variable; this will result in a malloc() call and be treated as a
leak.
In almost any program there are data structures which need to
survive until exit time, and of course exit processing does a fine
job of clearing them away. But this leaves the programmer with an
unfortunate choice: (a) to laboriously free everything just before
exiting or (b) to put up with lots of spurious warnings from
Valgrind. And of course, as with compiler warnings, trying to
manually skip over spurious warnings can often lead to the
important ones being missed.
It strikes me that it would be a real benefit for a programmer to be
able to make the assertion "I'm allocating this memory and I do not
plan to free it; it needs to stick around until exit time." Such as
a palloc() (standing for 'permanent alloc') function. This would be
semantically identical to malloc(), possibly even just a new symbol
pointing at the same address, and would exist only to make that
assertion for the benefit of Valgrind and friends.
Why not try it? Something like this:
#include <stdlib.h>
void *(*palloc)(size_t) = malloc;
So malloc ends up at, for example, 0x0b567440. The application makes
a
function call jump to 0x0b567440. Valgrind looks up 0x0b567440 in the
symbol table. Will it find "palloc" or "malloc"?
Doesn't Valgrind work on the source rather than the compiled object?
Bye, Jojo
.
- Follow-Ups:
- Re: why no palloc() ("permanent alloc")?
- From: Joachim Schmitz
- Re: why no palloc() ("permanent alloc")?
- References:
- why no palloc() ("permanent alloc")?
- From: Bernie Ohls
- Re: why no palloc() ("permanent alloc")?
- From: Joachim Schmitz
- Re: why no palloc() ("permanent alloc")?
- From: phil-news-nospam
- why no palloc() ("permanent alloc")?
- Prev by Date: Re: why no palloc() ("permanent alloc")?
- Next by Date: Re: why no palloc() ("permanent alloc")?
- Previous by thread: Re: why no palloc() ("permanent alloc")?
- Next by thread: Re: why no palloc() ("permanent alloc")?
- Index(es):
Relevant Pages
|
