[MPlayer-dev-eng] [PATCH][BUG] Incorrect memleak fix code in input/input.c might cause incorrect free

[Shachar Raindel]

On Tue, 3 Aug 2004 10:24:51 +0200, Alexander Strasser <eclipse7 at gmx.net> wrote:
> On Tue, Aug 03, 2004 at 12:35:56AM +0200, Alexander Strasser wrote:
> > On Mon, Aug 02, 2004 at 06:43:33PM +0200, Alexander Strasser wrote:
> > > On Mon, Aug 02, 2004 at 07:24:21PM +0300, Shachar Raindel wrote:
> > > > The patch this time is much more clean. I think I found the most
> > > > elegant solution - free file only if it is not the same as
> > > > config_file, and remove the weird stuff in the if added by alex. This
> > > > should do the trick, without any unneeded memory allocations (and BTW,
> > > > I was wrong about the ternary operator - only one of the expressions
> > > > is evaluate, so when one writes "a?b:c" than a is evaluated, and
> > > > afterward either b or c, but not both).
> > > Seems like a good and correct solution to me.
> > > I will commit it tonight if nobody objects.
> > Strangely your patch didn't apply, though that's no big problem for
> > this tiny patch...
> > But i got some doubts as i looked at the situation again.
> > So this is delayed until tommorow.
> OK, i knew i had some doubts and now i found why.
> Please look at the attached patch and comment.

Yep, I agree that this was a bug in my original patch. What about this
one? It is a bit more elegant IMHO, and you have only a single point
in which you free this chunk of mem, which makes it a tiny little bit
more clear... Don't know if this breaks buggy GCC compilers, and if I
should care.

Also, any particullar reason for having a prototype for get_path
inside the file, instead of having a single prototype for all of the
files that uses get_path, in a header file?

   Cheers,
   Shachar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: input-memleak-patch-3rd.diff
Type: text/x-patch
Size: 846 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20040803/421b72cb/attachment.bin>