This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: fix minor memory leak in symfile.c
- From: Tom Tromey <tromey at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 13 Sep 2008 11:56:02 -0600
- Subject: Re: RFA: fix minor memory leak in symfile.c
- References: <m3bpysugn4.fsf@fleche.redhat.com> <20080913171723.GH3714@adacore.com>
- Reply-to: Tom Tromey <tromey at redhat dot com>
>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:
>> While auditing other callers of build_id_bfd_get, I found a use of
>> 'free', so I fixed that as well. (Perhaps we ought to poison "free"?)
Joel> I think that's a good idea, since I don't think there is any case
Joel> besides the xfree implementation where we want to call free. Same
Joel> for malloc as well. But I'm not very familiar with the pros and
Joel> cons of this GCC pragma.
It works in the lexer, so it is fairly primitive.
I tried it and ran into a few problems. vec.h uses the token
'free'. struct dict_vector has a field named 'free'. And, bison uses
'free', but IIRC we #define it to xfree somewhere.
So, I think this probably isn't worth pursuing.
I did find a few stray uses of free. I can send that patch if you
like. I'm not even sure if this matters -- I suppose the
justification for xfree is not as strong as that for xmalloc.
Tom