2012/5/25 Iván Briano <[email protected]>:
> 2012/5/25 Bluezery <[email protected]>:
>> 2012/5/25 Vincent Torri <[email protected]>:
>>> On Fri, May 25, 2012 at 9:41 AM, Bluezery <[email protected]> wrote:
>>>> 2012/5/24 Carsten Haitzler <[email protected]>:
>>>>> On Thu, 24 May 2012 00:25:09 -0300 Gustavo Sverzut Barbieri
>>>>> <[email protected]> said:
>>>>>
>>>>>> You cannot cover all libraries as supposedly there will always be third
>>>>>> party
>>>>>> libs following that pattern. So far we can do many, but it's impossible
>>>>>> to
>>>>>> guarantee all.
>>>>>
>>>>> sure - and for those libraries - you need to follow their setup/shutdown
>>>>> mechanisms. for efl we have covered it all for the user - as of
>>>>> elementary we
>>>>> have.
>>>>
>>>> The underyling assumption is that init/shutdown is properly used for all
>>>> cases.
>>>> But in some cases, it does not. :( There can exist so many
>>>> libraries/applications/bugs/people to use EFL. We can not control all
>>>> those things and people. Furthermore, in top level application
>>>> developers's point of view, they should inspect all static/dynamic
>>>> libraries they use and find bugs and send patches and wait those are
>>>> fixed, and so on. This may be the best way theoretically. ;)
>>>> So I want that EFL init/shutdown functions can manage these problems
>>>> nicely. I mentioned this as previous mail
>>>> (http://www.mail-archive.com/[email protected]/msg41502.html).
>>>
>>> we CAN NOT predict how a lib is used by people. But we CAN
>>> say/document how it must be used. If it's documented and the user does
>>> not follow the rules, then it's his problem, not ours. In addition,
>>> that kind of _init()/_shutdown() is so much used in the same maner in
>>> libraries that it's useless to add more checks. There is one rule :
>>> _init() at the beginning of the program, _shutdown() at its end. End
>>> of discussion.
>>>
>>>> I do not know exactly where return value of init/shutdown is used for.
>>>
>>> usually, the returned value of _init is checked. If 0, it failed. I've
>>> never used the returned value of _shutdown, but you can :
>>>
>>> int main()
>>> {
>>> if (!ecore_init())
>>> return -1;
>>> // your code
>>> if (ecore_shutdown() != 0)
>>> {
>>> printf("error during shutdown\n");
>>> return -1;
>>> }
>>> return 0;
>>> }
>>>
>> This code assumes that users use init/shutdown CORRECTLY. But
>> init/shutdown can return non-zero even though init/shutdown actually
>> do nothing because init/shutdown is not correctly used in other places
>> What about the below cases?? those seems to be ridiculous but I do
>> not guarantee below does not happen even though I do correctly :(
>> because others can do not.
>> * ecore_shutdown (-1) --> ecore_shutdown (-2) --> ecore_init (-1)
>> If ecore_shutdown is called twice, ecore_init() should be called 3
>> times. So user should check return value in this case.
>> Also elm_init/shutdown are somewhat different from ecore_init/shtudown
>> in the code.
>> * elm_init ( 1) --> elm_shutdown (0) --> elm_shutdown(-1)
>> success! --> success! --> fail? (but last shutdown() do duplicated
>> finalization jobs.)
>> I think that this may be bug if guarantee.
>>
>
> void some_function()
> {
> Evas_Object *obj;
>
> evas_object_move(obj, 0, 0);
> }
>
> That code is wrong, but users may write something like that,
> should we try to avoid crashing when an invalid pointer is received?
> It can be done with a lot of awful and hackish code, or we can say
> "Write proper code or your shit won't work"
Hum.. I also do not want to guarantee that code :)
I only want to discussed about int/shutdown. These can be called &
mixed because we can use many libraries (EFL or not) which use
libraries (EFL or not) which use libraries (EFL or not), and so on....
Preventing this seems to be not so hard.
Anyway, if core EFL developers do not want this, End Of Discussion
Thanks. :)
>> So I have questions:
>> (1) EFL do not guarantee this incorrect/disordered usage? Actually I
>> want to guarantee :)
>> (2) If guarantee, init should be called 3 times if shutdown() is
>> called twice? I want once. :)
>> Above are just humble opinions.
>>
>>>> Actually current counter value does not check whether init/shutdown
>>>> is called or not if init/shutdown is not used properly/correctly as we
>>>> expected. Also almost documentations do not warn or remark users about
>>>> this.
>>>
>>> the counter is used for indirect calls, like:
>>>
>>> ecore_init();
>>> ecore_evas_init(); // ecore_evas_init() calls ecore_init(); so
>>> ecore_init() code is not called a second time
>>>
>>> same for _shutdown()
>>
>> If so, Is Eina_Bool just enough? :)
>>
>>>
>>>> So IMHO, I suggest that init/shutdown are better to be changed to
>>>> support disordered usage.
>>>> Or at least documentation should warn/remark about that.
>>>
>>> it should (must) be in the doc and tutorials. If it's not let's add it
>>>
>>> Vincent
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>
>>
>>
>> --
>> BRs,
>> Kim.
>>
>> ------------------------------------------------------------------------------
>> 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
--
BRs,
Kim.
------------------------------------------------------------------------------
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
