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

[Richard Frith-Macdonald]

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 <richard@tiptree.demon.co.uk>
> Date: 5 July 2006 08:09:58 BDT
> To: David Ayers <d.ayers@inode.at>
> 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.