On Tue, 8 Jan 2013 19:33:32 -0200 Gustavo Sverzut Barbieri <[email protected]> wrote:
> On Tue, Jan 8, 2013 at 7:17 PM, Michael Blumenkrantz < > [email protected]> wrote: > > > On Tue, 8 Jan 2013 19:57:30 +0000 > > Tom Hacohen <[email protected]> wrote: > > > > > I completely agree with Gustavo here. This is inconsistent and sounds > > like > > > a way to make it easier to ignore bugs. If you get a CRITICAL message, > > it's > > > never a false positive. At best it's mildly broken, usually more than > > that. > > > > > > > > > On Tue, Jan 8, 2013 at 1:33 PM, Gustavo Sverzut Barbieri < > > > [email protected]> wrote: > > > > > > > On Tue, Jan 8, 2013 at 11:24 AM, Michael Blumenkrantz < > > > > [email protected]> wrote: > > > > > > > > > because I changed it to ERR so it would not throw false positives > > when > > > > > debugging with abort on crit enabled > > > > > > > > > > > > > I'm wondering what would be a false positive. If NULL is to be allowed, > > > > then the function must check "if (ptr)" before everything, not > > producing > > > > errors at all. > > > > > > > > -- > > > > Gustavo Sverzut Barbieri > > > > http://profusion.mobi embedded systems > > > > -------------------------------------- > > > > MSN: [email protected] > > > > Skype: gsbarbieri > > > > Mobile: +55 (19) 9225-2202 > > > > > > > > passing null to a function is not a bug, and if I'm debugging and looking > > for real bugs I don't want to get a false positive from something stupid > > like this. > > > if it was not a bug, it wouldn't be producing any error messages. > independent of log level. there should be some if (!ptr) return; in there > if NULL are valid handles. > > In my point of view, NULL is as invalid as incorrect magic > (EINA_MAGIC_NONE). You were expecting something and got something else. > > Getting more concrete about your usage: could you provide some cases where > NULL is hurting you and it shouldn't? Would be better to fix the usage of > magic check? > the case where your way is detrimental: an app is throwing a critical error at some point. you want to catch it. you turn on EINA_LOG_ABORT. instead of getting an abort at the point you wanted, you get abort()ed at some other random point because someone didn't bother null checking a param to a function. you are unable to change application code, only provide suggestions for its change. as a result, you have no way to get past a useless magic failure and are unable to get to the real error. I understand your reasoning why you think that NULL is the same as EINA_MAGIC_NONE, but these are not the same things at all; NONE is what I would expect with a not-yet-initialized object. this is yet another case where we are being unnecessarily pedantic for real losses with no gain. ------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
