[MPlayer-dev-eng] [PATCH] Free GUI config

[Ingo Brückl]

Reimar Döffinger wrote on Thu, 28 Apr 2011 19:39:37 +0200:

> On Thu, Apr 28, 2011 at 10:52:02AM +0200, Ingo Brückl wrote:
>> > Freeing right before exit is after all a rather pointless thing to do,
>>
>> Well, the advantage of freeing it is that allocated memory can be freed,
>> isn't it?

> It will be freed on application exit anyway, which is why some people
> would call that "wasting lots of CPU cycles and energy to free them
> memory 1 ms earlier".

I had quite some difficulties to understand your last posting, and now I'm
realizing why.

It seems that the times when I started programing are far too far away. I'm
pretty sure I learned to properly release all memory I'm allocating. I am
stunned to come to know that it will be released anyway when the process
exits. (Seems that I am lacking some modern programing knowledge.)

> Obviously I don't fully agree with that, otherwise all those other
> frees wouldn't be there either.

That is a fairly vague statement. I would feel rather uncomfortable not
releasing what I've allocated.

>> Shouldn't there be a m_config_free() after GUI's m_config_new()
>> and shouldn't it be done right before exit, i.e. before gmplayer ends and
>> options are no longer needed?

> Well, I am asking you why you think it should.

At least for the same reason why there is a m_config_free(mconfig) around.
(It should be pointless then as well.)

> Or rather, why it should enough to justify adding Gui code there.

My only - obsolete - argument was waste of memory.

>> If an error occurs before initialization is finished,
>> guiDone() will never get called and thus the freeing will never be performed.
>> In mplayer.c (with the CONFIG_GUI) it will be performed in any case.

> When and why would that actually matter?

Although it no longer matters: At every exit_player...() between lines 2766
and 3024, including all aborts during GUI initialization (no skin, no draw
buffer).

BTW, I assume that the CONF_TYPE_STRING issue isn't then a problem either?

Ingo