Gabriel Sechan wrote:
> 
> 
> 
>> From: "James G. Sack (jim)" <[EMAIL PROTECTED]>
>> Stewart Stremler wrote:
>> >..
>> >>> 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?
>>
>> OK, I don't understand how the name bindings get resolved but, somehow
>> the magic works (, it seems).
>>
>> in memwatch.h:
>> ..
>> **  - mwMalloc() debugging allocator
>> **  - mwMalloc_() always resolves to a clean call of malloc()
>> ..
>> void* mwMalloc( size_t, const char*, int );
>> void* mwMalloc_( size_t );
>> ..
>> #define malloc(n)       mwMalloc(n,__FILE__,__LINE__)
>> ..
>> #define mwMalloc(n,f,l)     malloc(n)
>> ..
>> #define mwMalloc_(n)        malloc(n)
>> ..
>>
>> and then, there are real live implementations (that call malloc)
>> in memwatch.c:
>> void* mwMalloc( size_t size, const char* file, int line) {
>> ..
>> void* mwMalloc_( size_t size ) {
>>
>>
>> I wouldn't mind getting an explanation from somebody who knows, but..
>> ..it sure makes my head hurt!
>>
> Instead of calling malloc, mwMalloc makes OS level calls to request the
> memory itself (which is the same thing malloc usually does).  It then
> uses #define to override the default malloc, so any file that includes
> this file should use this malloc instead of the default one.
> 

Something like that would seem sensible, but in memwatch.c:893 (in V2.71)
  mw = (mwData*) malloc( needed );
this code is in
  void* mwMalloc( size_t size, const char* file, int line) {

similarly, mwMalloc_() also calls malloc()


So it seems that memwatch does it via a wrapper around standard malloc.

But the sequence of defines, proto declarations, and code definitions
puzzles me much. (As SS intimated,) it looks circular!

Regards,
..jim

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

Reply via email to