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.
Cheers,
David Ayers
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
