By the way, how to disable printing eina logs? AFAIK, user can't turn off the printing it.
------------------------------------ -Regards, Hermet- -----Original Message----- From: "Lucas De Marchi"<[email protected]> To: "Enlightenment developer list"<[email protected]>; Cc: "[email protected]"<[email protected]>; Sent: 2012-06-29 (금) 13:07:08 Subject: Re: [E-devel] Magic checks before NULL checks in Eina On Thu, Jun 28, 2012 at 12:05 PM, Michael Blumenkrantz <michael.blumenkrantz>@gmail.com> wrote: > On Thu, 28 Jun 2012 11:22:21 -0300 > Gustavo Sverzut Barbieri <barbieri>@profusion.mobi> wrote: > >> On Thursday, June 28, 2012, Michael Blumenkrantz wrote: >> >> > On Wed, 27 Jun 2012 23:43:23 -0300 >> > Raphael Kubo da Costa <rakuco>@FreeBSD.org> wrote: >> > >> > > Cedric BAIL <cedric.bail>@free.fr <javascript:>;>> writes: >> > > >> > > > I personally think that eina_iterator_free like any free function >> > > > should just work fine with NULL. I was against at that time, but >> > > > others won. So we do have this incoherency where some of our free >> > > > function work with NULL and some don't. >> > > >> > > So what can we do to improve the situation here (if it does need to be >> > > improved)? Speaking more generically, what criteria are used to decide >> > > that a function should be decorated with EINA_ARG_NONNULL and/or have >> > > magic checks performed? >> > > >> > >> > I am hugely in favor of having all _free() and _del() functions take NULL >> > arguments without erroring. >> >> >> I disagree, in regular situation it should never return a NULL handle, so >> you should never have a NULL handle to free. If that happened you did some >> mistake in the code and it's easier to spot and fix. >> >> Compatibility with libc is moot: should we also crash on other functions as >> well?! :-) >> >> >> >> > >> > >> > ------------------------------------------------------------------------------ >> > Live Security Virtual Conference >> > Exclusive live event will cover all the ways today's security and >> > threat landscape has changed and how IT managers can respond. Discussions >> > will include endpoint security, mobile security and the latest in malware >> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> > _______________________________________________ >> > enlightenment-devel mailing list >> > [email protected] <javascript:>;> >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > >> >> > > You're making a slippery slope argument (http://en.wikipedia.org/wiki/Slippery_slope). > > My statement, and the one I was referencing, was about free and delete > functions, not on all functions. Your insinuation that allowing silent passing > of a NULL param to deletion functions would cause crashes is inane; the purpose > of this is to simplify if (X) del(X), which is annoying and pointless. libc if (X) free(X) is very very very annoying. And we even have code in EFL doing that insane crap libc's free(). Regarding our _free/_del functions, I can't think of an example that shouldn't accept a NULL and just return (with *no* logging). Lucas De Marchi ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
