[CinCV TNG] [PATCH] Fix warnings and make guicast/stringfile.C handle longer length
einarry at smail.ee
Sun May 4 15:29:31 CEST 2014
On Fri, May 2, 2014 at 1:16 PM, Odin Hørthe Omdal <odin.omdal at gmail.com>wrote:
> On Thu, May 1, 2014 at 8:10 PM, Einar Rünkaru <einarry at smail.ee> wrote:
>> Are there other classes of compiler warnings you believe should be
>>> ignored by the project? I'll add them to the patch I prepare for
>>> increasing the amount of warnings reported by the compiler.
>> All warnings that force to use ugly workaronds should be ignored.
>> Warning may point to real bugs, sometimes. Sometimes it is useful to fix
>> the text to kill warning when it improves readability or makes harder to
>> write buggy code in the future.
> I think you have this the wrong way around. This warning *does* make it
> harder to write buggy code. Your (clearly) elitist attitude might cloud
> your judgement. Errors with assignment instead of comparison are something
> no-one ever thinks they'll do.
I know, I have made such errors
> But it doesn't work like that, bugs like that do in fact happen (even
> worse ones, see the bug Apple made in SSL). Silencing of errors that
> catches bugs is very far from professional software development.
Yes this is the example to take seriously warnings. But there are counter
example: killing a warning created a vulnerability.
> At Opera our code guidelines would not let "if (fp = fopen(..))" pass
> through (neither would it at Google, as far as I know). So I can't for the
> life of me understand why you'd veto such a change.
Big companys must have code writing policies in place. I think they
change their policies from time to time, but the do not apply their new
policies to old code.
You say it's harder to read, -- but others find it easier. I do at least
> for the explicit NULL check (and this is how our code base looks), so your
> argument does not pass the objectivity test.
Anyone can write a code as he/she wants. There are no certain rules how to
write a bug-free code.
> Of course you are free to veto things for whatever reason as the Cin
> guidelines say, but I'm baffled that you'd put prestige into such details
> that actually takes the project in a backwards position. IMHO.
> I also feel your attitude of aligning (where possible) with Cin4 to be
> destructive to the project. Lessening the gap between them should be an
> explicit goal, not some random reason for you to ridicule contributions
> (however small and simple).
Any change in existing code must be justified. There is no point add dead
code to a project (see the bug of Apple) - cinelerra contains enough of it.
When anyone wants to backport a working feature - this is fine. But this
feature must be useable by the user.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cinelerra