Stewart Stremler wrote:
>..
> Just to avoid the problems of a double-free, I pondered asking for a
> pointer to a pointer to a CircBuf. That way I could _set_ the pointer
> in the _Delete to NULL, and the _Create could check the pointer and do
> a _Delete if it wasn't null.
>
'coarse, the contrary user will just pass you a pointer to a copy of the
originally returned pointer <heh>;
>..
>> It's provided as memwatch.c and memwatch.h (which seems to need
>> inclusion after other headers -- at least, I had a compile error
>> reported from string.h if memwatch.h preceded other stuff including
>> string.h)
>
> I looked at the source, and I've discovered it uses one of the ugliest
> brace styles ever:
>
> if( expression){
> code;
> }
>
heh!
I've grown fond of
if( expression){
code;
}
which seems to be your preference, too. And I will even admit to
cuddled-else, on occasion.
> More significantly, I failed to see where the 'trick' was that I want
> to emulate.
It looks to me that it's simply hiding the malloc and free with defined
replacements (does that have any connection with weak references?)
memwatch.h:578
#define malloc(n) mwMalloc(n,__FILE__,__LINE__)
That also explains why I had to include memwatch.h _after_ stdlib and
string.h (it redefines strdup, too).
> ..I'm still thinking that the malloc_hook is the goat's bannanas,
> but then, that ties the test code into GNU-land, which means it's no
> longer portable. :(
>
>> Anyway it seems worth working with, maybe even making into a library
>> module, although explicit linking is easy emough.
>
> I'm leery of conditional-compilation for testing; the code that you end
> up running in the test isn't the code that you use in production.
I sympathize with the desire to minimize heisenberg effects, but
malloc_hook or even linking with substitute libraries would suffer some
amount of similar risks, wouldn't they?
>
>> There is a test.c example program as well as decent README.
>>
>> _memwatch looks good_
>> http://www.linkdata.se/sourcecode.html
>
> It's overkill for our little bit of code. :-/
>
OTOH, once you begin writing memory-test code, it may end up evolving
into a big thing anyway, just because there's so many problems one might
look for. I guess I'm more receptive to a build/production concept (for
some things).
Did I overlook where you said what kind of things you would stick in
your malloc-hook callbacks?
Regards,
..jim
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
