On Fri, Dec 6, 2013 at 10:19 PM, Carsten Haitzler <ras...@rasterman.com> wrote:
>
> On Fri, 6 Dec 2013 17:26:21 -0200 Gustavo Sverzut Barbieri
> <barbi...@gmail.com>
> said:
>
> > On Fri, Dec 6, 2013 at 10:42 AM, David Seikel <onef...@gmail.com> wrote:
> > > On Fri, 6 Dec 2013 10:12:09 -0200 Gustavo Sverzut Barbieri
> > > <barbi...@gmail.com> wrote:
> > >
> > >> On Thu, Dec 5, 2013 at 10:23 PM, Daniel Juyung Seo
> > >> <seojuyu...@gmail.com> wrote:
> > >> > Dear all, this is Daniel Juyung Seo.
> > >> >
> > >> > I propose EFL_SAFE_FREE macro for efl.
> > >> > It looks like:
> > >> >
> > >> > # define EFL_SAFE_FREE(_h, _fn) do { if (_h) { _fn((void*)_h); _h
> > >> > = NULL; } } while (0)
> > >> >
> > >> > As I have been using ELM_SAFE_FREE for months, I found out that
> > >> > this macro is quite useful in terms of code readability, reducing
> > >> > human mistakes, and using much smaller number of lines with the
> > >> > same functionality.
> > >> >
> > >> > Enlightenment has
> > >> > # define E_FREE_FUNC(_h, _fn) do { if (_h) { _fn((void*)_h); _h =
> > >> > NULL; } } while (0)
> > >> >
> > >> > Elementary has
> > >> > #define ELM_SAFE_FREE(_h, _fn) do { if (_h) { _fn((void*)_h); _h =
> > >> > NULL; } } while (0)
> > >> >
> > >> > So why not efl?
> > >> >
> > >> > By using EFL_SAFE_FREE, this (Old) code will reborn as a (New) code.
> > >> > 5 lines down to 1 line.
> > >> > (Old)
> > >> > if (svr->until_deletion)
> > >> > {
> > >> > ecore_timer_del(svr->until_deletion);
> > >> > svr->until_deletion = NULL;
> > >> > }
> > >> >
> > >> > (New)
> > >> > EFL_SAFE_FREE(svr->until_deletion, ecore_timer_del);
> > >>
> > >> bad name as there is nothing save in it.
> > >>
> > >> EINA_FREE_AND_NULL(ptr, freefunc) would be more descriptive, code is
> > >> the same. Or:
> > >>
> > >> EINA_FREE_AND_NULL(ptr) // does free()
> > >> EINA_DISPOSE_AND_NULL(ptr, disposefunc) // generic version
> > >>
> > >> I'm not a native speaker, eventually there is a better name for the
> > >> second one.
> > >
> > > Safe, as in "this is the safe way to do it", nothing to do with saving
> > > things.
> >
> > i know, but what is safe in it? Because it checks for null before
>
> the "safe" here is that it makes things safe afterwards. you no longer have a
> dangling pointer variable (in case you use it again now you've freed the
> object).
I've mentioned this over an over, while in some places we do want to
NULL the pointer because it is a valid value indicating something (ie:
no timer running, no object in use...) many others we do NOT want to
zero this pointer because the pointer shouldn't be used at all... and
if we stick a NULL and then check for such special value elsewhere
we're hiding bugs.
Also, if you set a pointer to NULL you lose valgrind tracing. If you
do not set to NULL you can get it to say that the pointer was freed
elsewhere and then you can easily trace why your bug happened.
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 9225-2202
Contact: http://www.gustavobarbieri.com.br/contact
------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
