id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,blockedby,blocking,branch_state,votes 125,allocate and free memory via mc-wrappers,slavazanko,slavazanko,"Now in sources mixed many technologies for working with memory: - system functions (malloc/free) - glib functions (g_malloc/g_free) - self-made function (like in vfs/mcserv.c:127) This patch is a first attempt to reorganize work with memory - only replace malloc with mc_malloc; g_malloc with mc_malloc, [g_]free with mc_free, etc. All definitions of mc_ placed in src/glibcompat.h. This not good place, I understand. Next step - create 'src/mc-alloc.[ch]'. This must be place of definitions memory-related functions; code from src/poptalloca.h and src/regex.c (related to definition of 'alloca' ) must will moved to mc-alloc module too. As fact, this patch is a refactoring of sources. I'm don't create mc-alloc at this time, because refactoring should made by little steps. This first step is prepare stage :) Advantages: 1) We can will realize garbage collector or debugger of memory leaks; 2) We can will realize own library 'mcglib' - for embedded systems it's very good; 3) In sources used only one technology of working with memory: mc-alloc (in future). And only in mc-alloc will use much different technologies; 4) More order in mind. :) Disadvantages: 1) All existing patches will need to hand processing... in many case. Because this patch will change a lot of files and applying patches via 'patch' or 'git-apply' command may will fail P.S. patch is too big and attached as gz-archive (because limit to size of attaches). ",enhancement,closed,major,4.7,mc-core,4.6.1,wontfix,memory,,157,,,