allocate and free memory via mc-wrappers

[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_<malloc|free|calloc|...> 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).

[slavazanko]

related with ticket:94

[Enrico Weigelt]

• Ticket System <tickets@…> schrieb:

ACK. But I'd like to go some steps further:

• introduce new macros

MC_MEM_ALLOC_Z() -> alloc on heap, zero'ing
MC_MEM_ALLOC_U() -> alloc on heap, uninitialized
MC_MEM_FREE() -> free from stack
MC_MEM_REALLOC() -> re-allocate (added space uninitialized)
MC_STACK_ALLOC() -> allocate on stack

• replace all other calls to malloc()+friends, mc_alloc()+co, by calling these macros

Could also be put into src/util.h
(BTW: we dont need any .c file for that)

ACK.

What should this mcglib actually contain ?

cu

[slavazanko]

Is we need to make these changes in this patch or in later refactoring process?

P.S. branch '125-allocate-and-free-memory-via-wrapper' was created.

[winnie]

Move this to a later milestone as this is really a restructurement of mc atm and the 4.6 series should be only a pure bugfix release.

This should go only to master not to mc-4.6 branch.

[slavazanko]

What should this mcglib actually contain ?

It's only for example ;)

This should go only to master not to mc-4.6 branch.

agree.

[metux]

meanwhile I've moved some steps further:
some .h files with macros+inlines in the ./mhl/ subdir
("micro helper library").

for example mhl/memory.h provides things like
mhl_mem_alloc_u(): alloc on heap, unitialized
mhl_mem_alloc_z(): alloc on heap, zero'd
mhl_mem_free(): free from heap
mhl_stack_alloc(): allocate on stack (uninitialized)

and mhl/string.h has eg:

mhl_str_dup(): safe strdup() (NULL->"")
mhl_str_ndup(): safe strndup()
mhl_str_concat_1(): cat 1 string onto some base str
mhl_str_concat_2(): cat 2 strings onto some base str
...

[slavazanko]

I think, in future need to move into ./lib dir - more sense place for library...

[slavazanko]

I think, need to fix this in any case, but in this ticket now I see proposal of MHL2... not good :)

[andrew_b]

(In #94) MMAP support in VFS was removed in changeset:bb14c4e1da234f7f204123e92acd0a3da20f576a\