Giel van Schijndel schreef:
> Christian Ohm schreef:
>
>> On Thursday, 28 December 2006 at 20:06, Dennis Schridde wrote:
>>
>>
>>> I think not too long ago Per said something like simply replacing MALLOC
>>> was
>>> not possible... Dunno if I remember that correctly or how his patch fixed
>>> that...
>>>
>>>
>> Just defining MALLOC/FREE to malloc/free etc. (see below) compiles a
>> binary that runs at least the tutorial for a short while (haven't done
>> more testing). So I guess we could just add those defines
>> unconditionally, and if nothing breaks for a while, remove them from the
>> code itself.
>>
>> --- lib/framework/mem.h (revision 579)
>> +++ lib/framework/mem.h (working copy)
>> @@ -78,5 +78,10 @@
>>
>> #endif // DEBUG_MALLOC
>>
>> +#define MALLOC(size) malloc(size)
>> +#define FREE(ptr) free(ptr)
>> +#define PTRVALID(ptr, size) (TRUE)
>> +#define MEMORYREPORT(file)
>> +#define MEMORYTREAP(file)
>>
>> #endif
>>
> While I'm sure that will work correctly in any release build I'm not so
> sure it will in the debug build.
> That's because the debug build assigns a struct around the malloc'ed
> memory for memory tracing.
>
> Also you might want to use a bit different define for FREE, the current
> codebase _might_ depend upon it, to prevent accessing freed memory:
> #define FREE(ptr) do { free(ptr); ptr = NULL; } while(0)
Ok, pretend I didn't say using malloc() and free() like that would work
fine. Because it won't, not as long as the blockheap memory system is
being used. This system turned on by memSetBlockHeap(!NULL) and off by
memSetBlockHeap(NULL), so before you can use plain malloc() and free()
you'll have to remove all calls to memSetBlockHeap() (blockheap system
is turned off on initialization of the memory system).-- Giel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
