Stewart Stremler wrote:
>..
> 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.

hmmm, strikes me the memwatch tool might allow some testing, say via its
mwLimit() operation. I suppose one might have to capture and/or parse
logs if in-code assertions don't suffice.

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

Now that I think of it, I seem to remember that this is useful for
testing long-running processes (eg, daemons) -- not sure but it does
kinda go with the name.

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

You're probably right. Places needing such code likely are concerned
with size and speed.

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

Ayup, but it does suggest a line of thinking that may have contributed
to things beyond C.

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

Hey!, I'd like to see 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?

Perhaps I am extrapolating with optimistic imagination. I'm thinking of:

1. code that can be accessed from any/all languages

2. moving more common operations from application into processing
libraries. I guess this is sorta just continuing a trend, but if strong
support for (1) is there, then I can imagine an explosion of (2).

>..

Regards,
..jim

-- 
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg

Reply via email to