begin quoting James G. Sack (jim) as of Sat, Sep 30, 2006 at 10:23:40PM -0700:
> 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>;
Contrary users may do whatever they please; trying to get around a
contrary user only makes a language ugly. (For example, "const". Ugh.)
It's not my desire to keep the user from ever doing something stupid; only
to keep the user from doing something stupid by accident.
[chop]
> > 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.
...except that I use more horizontal whitespace. :)
And yes, 1TB is my preference for C and Java (and it's required for TCL).
> And I will even admit to
> cuddled-else, on occasion.
I tend to write
if ( expression ) {
code;
} else {
code;
}
But I find
if ( expression ) {
code;
}
else {
code;
}
to be just wrong (and, in fact, error-prone), although I find
if ( expression )
{
code;
}
else
{
code;
}
to be readable. Go figure.
> > 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__)
But mwMalloc needs to eventually invoke malloc, yes?
> That also explains why I had to include memwatch.h _after_ stdlib and
> string.h (it redefines strdup, too).
Yup.
[snip]
> > 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?
But those are runtime changes. The code I'm investigating doesn't
change. It's Allowed to change the infrastructure *around* the code
being tested.
[snip]
> > 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.
Well, yes, but we're also running the risk of needlessly borrowing trouble.
Besides, if we evolve a big thing anyway, at least we can make sure to
evolve it into a C-unit-test-friendly system, rather than a post-analysis
system with files and suchlike.
> I guess I'm more receptive to a build/production concept (for
> some things).
It's a dangerous thing to have the test system be more complicated than
the code being tested. Test code should be mind-bogglingly tedious,
redundant, and long... but it shouldn't be complicated. Otherwise you
end up having to debug your (complicated) test system, which means we
probably ought to have unit tests for _it_...
And the snake eats its tail.
> Did I overlook where you said what kind of things you would stick in
> your malloc-hook callbacks?
No. I didn't get in to that.
--
_ |\_
\|
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
