Re: [AD] Addons and al_free and non-public functions

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2010-05-20, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> On Wed, 2010-05-19 at 14:11 -0400, Pavel Sountsov wrote:
> > I'm a little confused about when to use al_free/al_malloc and the 
> > non-existent al_realloc (can someone add it in?) in the addons. Should 
> > addons use those functions preferentially? How about the core, should 
> > it use those instead of _AL_MALLOC and the like?

Sorry, I forgot that _AL_MALLOC can pass context information.  If we
want to keep the malloc debugging capability (I think we do) then
al_malloc/al_free will need to be macros in the public API.

I don't like that _AL_MALLOC passes context information or not based
whether DEBUGMODE is defined.  I would like DEBUGMODE to be an
Allegro-internal detail, not something that users should have to define.

How about this?  The macros would be unconditionally defined:

   #define al_malloc(n) al_malloc_with_context(n, __LINE__, __FILE__, __func__)
   #define al_free(n)   al_free_with_context(n, __LINE__, __FILE__, __func__)
   #define al_realloc(p, n) ...

By default, Allegro won't do malloc debugging, so the context arguments
will just be ignored.  Since they are only constants, there should not
be any real overhead to passing them unconditionally.

al_*_with_context may be called with dummy arguments if necessary,
e.g. for language bindings.

Once all the Allegro code base consistently uses al_malloc (post-5.0)
the user would be allowed to override the vtable.

Peter