On 21/03/13 12:05, David Seikel wrote: > On Thu, 21 Mar 2013 11:37:53 +0000 Tom Hacohen > <tom.haco...@samsung.com> wrote: > >> 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. > > Agreeing with Cedric is an offence? I'll have to be careful with that > one, sometimes he makes sense. B-)
Didn't you get the memo? :) P.s, I meant: I just agreed with what cedric has said, he pointed out a common offence. ------------------------------------------------------------------------------ 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
