[FEATURE] Add support for custom allocation functions in generated list header

jgabaut / koliseo

An arena allocator library in C.

https://jgabaut.github.io/koliseo-docs

GNU General Public License v3.0

5 stars 0 forks source link

[FEATURE] Add support for custom allocation functions in generated list header #69

Open jgabaut opened 6 months ago

jgabaut commented 6 months ago

At the moment, the base for allocation in the list generated header when using _gl() functions is malloc().

Source

Support for custom allocation could be added.

khushal-banks commented 5 months ago

malloc is used in 3 contexts by koliseo

In, LIST_cons_gl function
Whenever, KLS_Region type needs memory
and with some macros related to KLS_Conf

Note: KLS_DEFAULT_ALLOCF is malloc

Support for custom allocation could be added.

Custom allocation if implemented would be used by all LIST, REGION & CONFIG types? Or custom allocation will be targeted for only LIST_cons_gl function ?

jgabaut commented 5 months ago

Custom allocation if implemented would be used by all LIST, REGION & CONFIG types? Or custom allocation will be targeted for only LIST_cons_gl function ?

As title says, this issue refers to the eventual support for a different "global" allocator for the macro-generated code in list header.

The unrelated KLS_DEFAULT_ALLOCF (for internal usage, like the ones you mentioned) is already only defined when the macro is not predefined before the inclusion, so you can customise that already.

jgabaut commented 5 months ago

malloc is used in 3 contexts by koliseo [...]

and with some macros related to KLS_Conf

I was curious what you meant by that, I don't understand this last point. Could you elaborate?

To clarify:

KLS_DEFAULT_ALLOCF is called when initialising a new Koliseo with kls_new() (default definition is malloc)
malloc is used for any new created Region when the allocation backend for the Koliseo receiving the Region is KLS_REGLIST_ALLOC_LIBC

I'm just stating the current workings, not really saying they have to stay this way. Custom allocation could also be supported for the Region list backend, but it's not a priority.

khushal-banks commented 5 months ago

I wanted to understand how different memory allocations in kaliseo would be effected by this change. I was hoping that usage of memory allocation would be implemented in similar way for all these three cases.

If you happen to finalize steps/changes required to close this issue. I would love to attempt it. :)

jgabaut commented 5 months ago

all these three cases.

My previous question was about specifically the last point, I don't understand what you mean by:

and with some macros related to KLS_Conf

khushal-banks commented 5 months ago

kls_new(), kls_new_conf(), kls_new_traced(), kls_new_dbg() and kls_new_traced_AR_KLS() all these macros are using KLS_DEFAULT_ALLOCF

I thought a uniform allocator would be implemented every where. So i mentioned it to know more.

The unrelated KLS_DEFAULT_ALLOCF (for internal usage, like the ones you mentioned) is already only defined when the macro is not predefined before the inclusion, so you can customise that already.

You cleared my doubt with above reply.

jgabaut commented 5 months ago

kls_new(), kls_new_conf(), kls_new_traced(), kls_new_dbg() and kls_new_traced_AR_KLS() all these macros are using KLS_DEFAULT_ALLOCF

I thought a uniform allocator would be implemented every where. So i mentioned it to know more.

I now understand, the calls related to KLS_Conf are the pre-configured initialiser functions. Thanks for the patience.