all i can say is, if you're programming in C or C++, on a platform that valgrind supports, and you don't use valgrind - you're shooting yourselves in the leg. nothing comes even close to valgrind in the list of malloc debugging libraries - because valgrind is not a malloc-debugging library - it's a code instrumentation tool, and thus has much more control on the program being debugged.
if you haven't tried it - try it now. --guy On Sat, 2006-09-30 at 19:58 -0700, Stewart Stremler wrote: > begin quoting James G. Sack (jim) as of Sat, Sep 30, 2006 at 01:46:18PM > -0700: > > - - - > > continuation from main list of the thread: > > Re: Circular buffers (Was: C-based data structures library (like Boost > > but for C)?) > > - - - > > > > <CONTENT-WARNING > > beware-list="armchair-expert, handwaving, computer language ramblings" /> > > /me laughs > > > Stewart Stremler wrote: > [chop] > > > But it's that first trick I don't remember how to do. Wanna pick > > > this up in LPSG? > > > > Hmmm, it's been a long time, but I think I always relied on debug-build > > behaviors that diddled malloc/free . In this simple case, I suppose one > > might consider a manual substition of myMalloc myFree wrappers -- but > > somebody's already done that for us, I'm sure. > > > > Hmmm, know anything about mtrace (man 3 mtrace -- from glibc-utils)? > > Nope. > > But the manpage pointed me to malloc_hook, which looks like what we > need. > > I found another approach at > > http://okmij.org/ftp/syscall-interpose.html > > ...which uses ld to basically accomplish what I was thinking of doing. > > I have another thought (involving function pointers) that I might look > at. Dunno if it would work, however. > > > I also see mention of memwatch and dmalloc. > > These above found via > > Memory Leak Detection in Embedded Systems > > http://www.linuxjournal.com/article/6059 > > These don't seem to lend themselves to unit-testing, alas. > > > Now, I've also heard of valgrind, but never used it. I'm sure a > > 'regular' c-programmer must know about and use all these things, everyday. > > Again, not something that lends itself to using in a unit-test. > > [snip] > > Looking at the original question, as well as past posts on related > > subjects, it is fun to ask/remark: > > > > People have probably been writing circular buffer code since before > > Carl was in undergrad school -- why don't we have some nice reusable > > choices in widely available libraries. > > Because most of the time, the buffer is tightly tied to the type of data > being buffered, and it only takes a page or two of code to implement. A > library version will by necessity be more generic, and thus contain > excess code and overhead. > > I would suspect that the greatest need for ring buffers is in low-level > drivers, where tight coupling to ASM is king. Not something that you'd > use a library function for. > > > C does not make it easy to write object-like code. > > But it does lend itself to modular programming, which is most of the > way there. And, often, that's good enough. > > > One thing in > > particular, you have to use some type-casting which kind of detracts > > from the benefits argued for static typing. Hmmm.. wonder what > > Objective-C is like? > > Should I write up a version of the circular buffer in Objective-C? You > can contrast and compare. :) > > (Hm. There's nothing already in the foundation classes. I'm suprised.) > > > Thinking about Chuck Esterbrook's posting, makes me admit that > > Microsoft's (or whoever they stole it from) work on Common language > > Runtime addresses a long-standing need. > > Why? > > Hasn't this need been fulfilled more than once? > > > 'course, I sure would like the > > library code to be open, because that's one of the big things that > > chased me away from MS originally. It's now an even stronger requirement > > (open code), given the potential for bad behavior by the bad guys. > > Heh. > > -- > _ |\_ > \| > -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
