On 4 Jul 2006, at 19:34, Peter Cooper wrote:
On 2006-07-04 19:00:42 +0200 Richard Frith-Macdonald
<[EMAIL PROTECTED]> wrote:
Hmm ... I started reclassifying these as category ';change
request' rather than 'bug' and severity 'wish' rather than
'normal' since these are plainly not bugs, just (mostly) spurious
compiler warnings
However, I'm not sure that's the right thing to do ..
Should they be closed as 'invalid' instead? I'm inclined to think
it would be nice to change code to avoid spurious compiler
warnings as a very low priority issue, but perhaps others feel
different
I think Patrick's bugs are real bugs - compiler warnings exist for
a reason.
Certainly they do ... but the fact that a compiler issues a warning
does not mean that there is a bug ... it means that the compiler has
found some code that tits developers think is of a form more likely
to be a bug than most.
There is generally much debate about adding compiler warnings, since
some people take the view that particular warnings do more harm than
good, especially since the compiler sometimes gets things wrong.
Clean code bases lead to real risks being noticeable immediately,
as opposed to skulking silently until causing weird errors or
security problems.
Sure .. and the GNUstep codebase is very 'clean' that way ... we
build with lots of warnings turned on and generally write code which
does not generate warnings ... but that's pretty tricky when
different compiler versions generate different warnings under
different conditions.
For instance, new versions of gcc added a warning about dealloc
implementations not calling [super dealloc], and I recently went
through the base library hacking in a perverse workaround to prevent
the compiler from issueing that warning. In every single one of the
cases where I had to do this the existing code that the compiler was
warning about was correct, and the changed code is (marginally) less
efficient and less clear. So, while the warning may generally be
useful (I know that forgetting to call [super dealloc] is a fairly
common coding error), it's purely harmful in the gnustep libraries.
So, the point of a compiler warning is to check and see if there is a
bug ... but it's not a bug in itsself.
Having code not cause warnings is desirable because the presence of
spurious warnings can obscure real problems, but that's not the same
thing as sayiung that code which causes compiler warnings is buggy.
Submission of patches to work around the compiler and stop it warning
about things that are OK are very welcome, and reporting an analysis
of code being warned about in the case where there really is a bug is
also very useful, but reporting compiler warnings as if they were
bugs is pretty pointless ... it's not going to make those compiler
warnings any more obvious to developers.
_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep
