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-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
