Raster and I completely agree here, so you can see most of "my" response in his email in his words. :)
But there's one more thing I wanted to add: I love error-free and defensive coding, I think it's good and needed. I'm not arguing here whether we should write safe code or not, I'm arguing about the extent. For example, you want to have a safety switch on a gun, but you don't want one that prevents you from shooting fast and efficiently. So yeah, sometimes you have misfires, but that's the price you sometimes pay for performance, costs, and efficiency. I think we need checks, for example the magic checks in evas (and everywhere) are great. Why? Because the error cases we test there are actually plausible, we print an error and they can be disabled. We already agreed that the fact that the patch as is doesn't print any errors is bad, I guess you agree that such checks need to be possible to disable, so I only have to convince you about whether they needed in general or not, so I'll focus on that. I'm arguing that NULL checks everywhere are not really needed and they don't cover common cases. Yeah, in some cases they make sense, but in others, they do not. It's highly implausible that an eet file will be NULL, as those are usually handled locally in one context in which the values are known (I hope it's a good enough example). Following the same "safe coding" logic we should add magic checks everywhere, i.e to every struct we ever allocate, just because a user could pass an already freed pointer (for example). Again, the main point, is that we can only protect people from their mistakes to some extent, and I'm not sure the 0.083% increase of "stability" (if you call a completely misbehaving but not crashing app a stable one) is worth the extra effort, bloat and etc. Side note: are you sure people that write that crashing code actually look at the stdout/err prints and bother with fixing them? As I'd expect that type of people to just ignore the errors and say something like: "ah, that's a library bug, not me, that print is not important". -- Tom. On 05/09/12 19:14, Daniel Juyung Seo wrote: > On Wed, Sep 5, 2012 at 11:31 PM, Tom Hacohen <tom.haco...@samsung.com> wrote: >> On 05/09/12 17:18, Daniel Juyung Seo wrote: >>> >>> On Wed, Sep 5, 2012 at 10:12 PM, Tom Hacohen <tom.haco...@samsung.com> >>> 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. > > No, I didn't say "I support the patch", I just said "we should check > null at least for public apis." > I didn't even read the patch. > > My email was against your email not the patch itself. > > I repeat. I don't want to hide bugs. I want my product to be stable in > terms of crash and just warn it with error message for dumb users. > >> >>> >>>> >>>> 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. >> > > Anyhow we should change them locally before a real product release. > And others who want to make stable(in terms of crash) products will do > the same local changes for EFL libraries. > > I am sick and tired of hearing that "EFL code sucks" because of those > missing exception handlings. > > Daniel Juyung Seo (SeoZ) > >> -- >> Tom. >> > ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
