On 21/03/13 11:22, Michael Blumenkrantz wrote: > On Thu, Mar 21, 2013 at 11:10 AM, Tom Hacohen <tom.haco...@samsung.com>wrote: > >> On 21/03/13 11:00, Mike McCormack wrote: >>> On 03/21/2013 09:25 PM, Tom Hacohen wrote: >>> >>>> Silencing warnings just for silencing is not good. We use them to spot >>>> bugs, that's why we like them so much. Silencing useful warnings is >>>> counter-productive. >>> >>> Usually a developer, upon checking out a code base and building it on >>> their system and observing a nice warning free compile will have a sense >>> of confidence in a project. >> >> Yes. And we don't want to break that trust by creating false confidence >> just by silencing the warnings, even ones that my point to bugs. >>> >>> Usually a developer, on making a modification to their code, checks for >>> warnings and makes sure none have been introduced before pushing their >> code. >> >> Yes, that's cedric's fault, no doubt, but still, just blindly silencing >> these warnings will not help cedric fix the broken code. >>> >>> There are some people who wish to compile their code with every frickin >>> warning in the world turned on, then proceed to ignore said warnings, >>> and commit code with warnings to their revision control systems. >> >> I didn't quite get what you are talking about here. >>> >>> That gcc somehow changed which warnings it emits in a newer version >>> changes none of the above. >>> >>> Enjoy your warnings. >> >> Dude, you know me, you know I'm pro-fixing warnings. However, shushing >> important warnings that point out bugs just to silence the build is not >> a good thing... I think you subconsciously linked this thread with the >> one you had with demarchi. We are talking about completely different >> things. >> >> Cedric just pointed out, and I agreed, that people shouldn't just shush >> important warnings just for the sake of it. They should either fix them, >> or make whoever introduced them fix them. That's it. >> >> -- >> Tom. >> > > pretty sure neither of the cases were "blindly silencing warnings". > > one of the changes made was to use the correct free function, preventing a > magic failure and a leak. > another was to add a format string and prevent undefined behavior with > fprintf; the only issue here was that I added a trailing newline. since > we're exaggerating here, I guess I had better delete my commit access since > the newline broke build, prevented E from starting, and caused an orphanage > to catch fire somewhere in Africa. > > starting a troll war on the mailing list without knowing what you're > fighting about is not a productive use of anyone's time.
Huh? I didn't comment on your code. Heck, I didn't even look at the diff. I just agreed with what cedric has said, which is a common offence around here. -- Tom. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel