I think that maintain issue is more important than performance. (except kernel or etc..) and there are so many dumb developers like me :) 2012. 9. 6. 오전 1:15 Daniel Juyung Seo <seojuyu...@gmail.com> 작성:
> 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 ------------------------------------------------------------------------------ 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
