Dennis Schridde schreef: > Am Freitag, 29. Dezember 2006 23:18 schrieb Giel van Schijndel: > >> Dennis Schridde schreef: >> >>> Am Freitag, 29. Dezember 2006 16:12 schrieb Giel van Schijndel: >>> >>>> Well, I've done some cleaning up in the memory system, result is the >>>> attached patch. >>>> >>>> This patch does the following: >>>> * remove lots of code that never gets executed (because of if(0), >>>> #if(0), or by using other condition checking which always sees a 0 as >>>> condition through some kind of function or variable). >>>> * remove code that doesn't actually do anything ( debug ( LOG_NEVER, >>>> "..." ); included) (e.g. calculating and assigning values to a variable >>>> which then never gets referred again) >>>> * remove code that *does* do something but is completely useless (e.g. >>>> setting all memory to 0x00 before passing it to free() ) >>>> * remove a whole lot of (unused/uncalled) debugging functions that do >>>> nothing more than outputting/printing stats about the current state of >>>> the memory allocations/usage >>>> * remove (or comment out) code that encourages buggy programming (e.g. >>>> assuming all acquired memory is initialized) >>>> * remove some preprocessor macros which don't ever get used (yes, I >>>> searched/scanned every single source file in the trunk) >>>> * turned some ASSERT (FALSE, "...") statements into the condition they >>>> are actually guarding rather than depending on the programmer to go and >>>> look for the if(...) condition right above this ASSERT >>>> * fixed (two I believe) some compiler warnings >>>> * inserted some comments to clarify what some very odd looking >>>> non-intuitive code does >>>> * moved variable declaration more down into code where it is >>>> initialized (i.e. applying RAII there where it easy to do so) >>>> * fixed some minor bugs (e.g. triggering two ASSERTS, while the first >>>> one was well enough to predict the second one would occur as well) >>>> >>>> If I've done everything correct, then all this patch should do is >>>> cleanup code _almost_ (i.e. some double triggered asserts will be gone, >>>> and some bugs because of lacking RAII will now not occur) without >>>> altering the program's behaviour. >>>> >>> Are you sure the removal of memMemoryReport() from memShutDown() doesn't >>> change anything? I remember reading some memory allocation stats on game >>> close... >>> >>> There are also some LOG_NEVERs which don't seem so unused... >>> >>> never: blkReset: ../src/init.c at 1024: memory allocated : >>> never: blkReset: ../src/init.c at 1024: memory usage: >>> never: Blocks allocated 24525k, Memory allocated 4484k >>> >>> memory: memMemoryReport: No memory allocated >>> > If the memMemoryReport will ever only output "No memory allocated", then ok. > I wonder though how the other report is created... And it seems to have some > value. If that is not true, this lines are generated by some other function > (you did not remove) or they output only some invalid numbers, then I don't > fear to remove them either. > I just wondered why you seemed to remove something which seemed to have some > sense. If it hasn't, it's ok, remove them... > If you really mean output generated like that which you've quoted above (i.e. only the never: ... lines) then that output is generated by blkReset (in block.c) which doesn't use memMemoryReport. It does use memRecReport though, but that one is only called (ignoring its return value) while it really doesn't print anything when REALLY_DEBUG_MALLOC isn't defined.
-- Giel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
