Re: [bug #16997] compiler warning for NSZone.m

[David Ayers]

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