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

Reply via email to