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
However, I'm not sure that's the right thing to do ...
Should they be closed as 'invalid' instead? I'm inclined to
would be nice to change code to avoid spurious compiler warnings
very low priority issue, but perhaps others feel different?
Thats a bad idea because there very well could be an actual bug
just doesn't randomly warn you. Its better to actually fix these,
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
actually fix the code that causes the warnings then close them
theres no bug.
FWIW, I'm also an advocate of 0 warnings but in some of these
warnings are indeed spurious. These should be reported as bugs
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. */
- [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*)
/* In the following method the version of class named trueName is
fix the warning, then I believe we are working around GCC bugs while
actually potentially masking future bugs in GNUstep behind the new