Oops .. I hit 'reply' when I meant to do 'reply all' ... so thjis
didn't go to the list originally.
Begin forwarded message:
From: Richard Frith-Macdonald <[EMAIL PROTECTED]>
Date: 5 July 2006 08:09:58 BDT
To: David Ayers <[EMAIL PROTECTED]>
Subject: Re: [bug #16997] compiler warning for NSZone.m
On 5 Jul 2006, at 07:22, David Ayers wrote:
Patrick McFarland schrieb:
On Tuesday 04 July 2006 13:00, Richard Frith-Macdonald 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?
Thats a bad idea because there very well could be an actual bug
there. GCC
just doesn't randomly warn you. Its better to actually fix these,
then close
them as invalid.
Closing them as invalid, of course, would be marking them as not
a bug, which
as I just said, there may actually be buggy code there. Its
better to
actually fix the code that causes the warnings then close them
thinking
theres no bug.
FWIW, I'm also an advocate of 0 warnings but in some of these
cases the
warnings are indeed spurious. These should be reported as bugs
against
GCC instead, if they are not already.
If patches like this:
--- /libs/gui/trunk/Model/GMArchiver.m 2006/07/04 20:27:04 23125
+++ libs/gui/trunk/Model/GMArchiver.m 2006/07/04 21:31:49 23126
@@ -289,7 +289,7 @@
-encodeObject: withName: message, save its label into the
topLevelObjects array. */
if (!level)
- [topLevelObjects addObject: (name ? name : label)];
+ [topLevelObjects addObject: (name ? (id)name : (id)label)];
lastObjectRepresentation = objectPList;
@@ -579,7 +579,7 @@
{
id inArchiveName = [(id)NSMapGet(classes, trueName) className];
- return inArchiveName ? inArchiveName : trueName;
+ return inArchiveName ? (NSString*)inArchiveName : (NSString*)
trueName;
}
/* In the following method the version of class named trueName is
written as
fix the warning, then I believe we are working around GCC bugs while
actually potentially masking future bugs in GNUstep behind the new
casts.
Yes ... while I think that the chance of these changes masking a
new bug is very small, there is no doubt in my mind that the
resulting code is worse than the original code. The reason for
making such changes is that, if you don't aim for zero (or very
few) warnings, you end up losing useful warnings in all the
messages, so it's a trade-off between slightly poorer general code
quality in order to avoid the warnings, or turning off the warnings
in the compiler and losing the compilers ability to tell you about
real problems.
I don't think that the number of bogus warnings produced by the
compiler is yet close to making it preferable to turn off warnings,
and I hope that the compiler never really approaches that stage.
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
