Re: [E-devel] Add Null Chekcing Routine in eet_lib

[Vincent T. <vin...@gm...>]

On Wed, Sep 5, 2012 at 4:31 PM, Tom Hacohen <tom...@sa...> wrote:
> On 05/09/12 17:18, Daniel Juyung Seo wrote:
>> On Wed, Sep 5, 2012 at 10:12 PM, Tom Hacohen <tom...@sa...> wrote:
>>> Why should we? It makes really no sense. And if you want to rely on "past
>>> experience" i.e what people do, instead of sense, take a look at libc:
>>> free, strlen and strcpy are just a few of the many examples that don't
>>> accept NULL. Having sanity checks everywhere is not "safer", it just hides
>>> bugs at best, slows everything down, bloats the code and makes me want to
>>> hate myself.
>>
>> I didn't say "hide bugs". We should warn it by using error message.
>> I didn't say slow things down. If we don't check NULL, all apps also
>> have to check NULL for all EFL APIs anyway.
>
> No, apps can check in a centralized manner, i.e 1 check for multiple
> calls, and not check in many cases. It's not even slightly the same. Wrt
> hiding: you said you support the patch, and the patch doesn't print or
> do anything, it's just hiding bugs.
>>
>>>
>>> Also, these tests in specific are not good enough. Such tests should be
>>> wrapped in macros that print a warning about the error case so users will
>>> avoid doing them in the future (if applicable), let you disable them, and
>>> are generally consistent.
>>
>> Yes, this is what I want. At least we should avoid crashing and warn
>> them with error message.
>
> That's the least we should do if we decide to do checks.
>>
>>>
>>> Also, there's a very limited list of reasons why to do sanity checks:
>>> 1. If only we can do and the user can't.
>>> 2. If the checks are a lot easier for us to do than the user.
>>> 3. Very common checks that should be everywhere and we'll be saving a ton of
>>> code by doing them ourselves, and no, this doesn't apply here.
>>>
>>
>> Two more things,
>> 1. I don't trust users.
>> 2. If EFL is used in your hobby project, I don't care. But if EFL is
>> used in a real product, I will not allow apps to crash so easily only
>> by calling EFL APIs with NULL.
>>
>
> You use glibc, don't you? Why do you use it and strlen and not
> my_null_checking_strlen? Saying one thing is professional without
> backing it up is hardly an argument. Yeah, defensive programming is
> good, but only to some extent, some mistakes are just too bad to ignore
> or handle. If poor programmers want to crash their apps they will, even
> if we add this tiny bit of protection that will bloat the hell out of
> our code, waste our time, and make the world a bit worse place to live in.

when the doc is explicit, there is no problem

i've written the eina_array doc and said (iirc) that no checks are
done in the arrays that are passed to the inlined array functions. If
the user don't read the doc, it's his problem, not our

Vincent