On Tue, Jan 8, 2013 at 10:15 PM, Gustavo Sverzut Barbieri <
[email protected]> wrote:

> On Tue, Jan 8, 2013 at 7:42 PM, Michael Blumenkrantz <
> [email protected]> wrote:
>
>> 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.
>>
>
> I'd say it's better to 1) breakpoint inside eina_magic_check that does
> what you're looking for; 2) create EINA_MAGIC_ABORT={all,null,invalid,none}
> and do it independently from eina_log.
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: [email protected]
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>

1) non-EFL developers will not understand this and it will be an annoyance
2) while I agree that having this sort of granularity is nice sometimes,
having too many options is bad. I don't want to have to set 10 different
environment variables which have different string enum values that I have
to remember in order to debug an application, I want my one variable to
work better.
a better solution for #2 would be to simply change it to a SAFETY macro and
then add an env variable to toggle aborting when one of these fails. this
keeps things simple and allows us to make use of existing APIs; magic check
is NOT for finding the case of passing NULL pointers to functions, that's
why we have an entire separate API for doing this.
------------------------------------------------------------------------------
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to