[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Richard Frith-Macdonald
Subject: Fwd: [bug #16997] compiler warning for NSZone.m
Date: Wed, 5 Jul 2006 09:04:53 +0100

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 <address@hidden>
Date: 5 July 2006 08:09:58 BDT
To: David Ayers <address@hidden>
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]