[CinCV TNG] [PATCH] Fix warnings and make guicast/stringfile.C handle longer length

Einar Rünkaru 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...
URL: <http://lists.cinelerra-cv.org/pipermail/cinelerra/attachments/20140504/3c133535/attachment.html>

More information about the Cinelerra mailing list