Re: [patch] PR python/10807 API for macros.

[Matt Rice <ratmice@gmail.com>]

On Wed, Aug 17, 2011 at 4:09 AM, Phil Muldoon <pmuldoon@redhat.com> wrote:
> Matt Rice <ratmice@gmail.com> writes:
>
>
>>> What do you mean by inconsistent memory management?  Can you expand/explain
>>> this.  Do macro definitions have a life-cycle in GDB?
>>
>> depends on the source of the macro, xmalloc directly for user-defined,
>> or the macro table's obstack.
>>
>> from macroscope.c:
>> /* A table of user-defined macros.  Unlike the macro tables used for
>>    symtabs, this one uses xmalloc for all its allocation, not an
>>    obstack, and it doesn't bcache anything; it just xmallocs things.  So
>>    it's perfectly possible to remove things from this, or redefine
>>    things.  */
>>
>> I'm second guessing myself that caching the macro_source file is safe though.
>
> Is there life-cycle management for macros?  (See py-symbol.c for
> life-cycle management of symbols).  If so, we should invalidate (but keep
> around) the macro Python object, but run a validity routine to check
> that the macro exists.

Yeah, there is.

I was confused by free_macro_table != a destructor.
it seems to be there to discard macro_tables in the case of 'early retirement'
they can *poof* via obstack regardless of free_macro_table.

I'll just get rid of this for now, and do a deep copy of the macro on
initialization,
and see how that works with the macro iterator mechanism we discussed.

revisit it later when i can figure out how to get at the obstack, and
get it working correctly
with the obstackless macro tables, we can change this under the hood
without changing the API...

I suppose i should add an is_valid method that just returns True for
now with the deep copy.

> If not, then I am not sure.  If you cache the macro_source file, do you
> keep it around forever?  I am also unsure if it is ok to do this.

just as long as the macro_object *, so potentially forever.