[webkit-efl] Issues from static program analysis tool(s)

[Rafael Antognolli]

Dear Kangil,

I understand why you are worried, EFL has changed it's API a lot over
the years, and that has always broken applications code. But this
shouldn't happen anymore, at least not with Eina, Ecore, Evas, etc.

These libraries are 1.0.x now, signature and behavior of existing
functions won't change until EFL turns 2.x, and that will be in a very
distant future. When that happens, then probably a lot of the code of
webkit-efl will need to be rewritten, and then this part will need to
be changed too.

If you follow the EFL mailing list and #edevelop, you'll see that
nobody is changing existing API, and that everyone is actually against
that. Only new API will be added with 1.1, 1.2, and so on. That's why
there's no need to worry about external package upgrade.

Regards,

On Thu, Jul 28, 2011 at 10:10 AM, Kangil Han <kangil.han at samsung.com> wrote:
> Dear Rafael,
>
> First of all, your mention makes sense.
> In this case, double check seems useless.
>
> About my latest mention "strict view in programming", I apologize that I
> generalized so much.
>
> However, there is an argument that double check is needed because evas API
> will be upgraded.
> Currently, you are right, evas_object_smart_data_get() can handle NULL
> argument.
> But, in future, who can be sure?
> From this reason, some developers here want to minimize the effect from
> external package's upgrade.
>
> Thanks and regards,
> Kangil
>
> -----Original Message-----
> From: Rafael Antognolli [mailto:antognolli at profusion.mobi]
> Sent: Thursday, July 28, 2011 9:48 PM
> To: kangil.han at samsung.com
> Cc: webkit-efl at lists.webkit.org
> Subject: Re: [webkit-efl] Issues from static program analysis tool(s)
>
> On Thu, Jul 28, 2011 at 4:24 AM, Kangil Han <kangil.han at samsung.com> wrote:
>> Dear EFL developers,
>>
>>
>>
>> I am writing this to hear your voices on the issues from static program
>> analysis tool.
>>
>> ‘Coverity Static Analysis’ can be a tool of those.
>>
>>
>>
>> For example, lately I’ve got a below report.
>>
>> There should be null check for ‘o’ in ‘EWK_VIEW_SD_GET(o, ptr)’ macro.
>>
>>
>>
>>
>>
>> #define EWK_VIEW_SD_GET(o, ptr)                                 \
>>
>>     Ewk_View_Smart_Data* ptr =
>> (Ewk_View_Smart_Data*)evas_object_smart_data_get(o)
>>
>>
>>
>> If we only look at this macro, report seems clear.
>>
>> But, when it comes to look ellE>evas_object_smart_data_get’ function, this
>> point is not so clear.
>>
>> This is because ‘evas_object_smart_data_get’ function can handle NULL
>> argument of ‘o’.
>>
>> However, if we should have strict view in programming, this report makes
>> sense.
>
> Why?
>
> What do you mean by "strict view in programming"?
>
> This macro considers that NULL is a valid value for 'o', because the
> function evas_object_smart_data_get() can handle it (by checking it
> internally). What benefits do you have by double checking this?
>
> For me, that's just a false positive of the static analysis.
>
> Regards,
> --
> Rafael Antognolli
> ProFUSION embedded systems
> http://profusion.mobi
>
>



-- 
Rafael Antognolli
ProFUSION embedded systems
http://profusion.mobi