[Top][All Lists]

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

[objc-improvements] Warnings when compiling GNUStep

From: Ziemowit Laski
Subject: [objc-improvements] Warnings when compiling GNUStep
Date: Tue, 2 Sep 2003 17:17:26 -0700

The objc-improvements-branch compiler can now successfully churn its
way through the GNUstep compile-all script, although it does produce
some new warning messages along the way, and I wanted to solicit your
opinion as to what (if anything) to do about it.

First and foremost, we have numerous instances of the following:

  GSObjCRuntime.m: In function `GSAutoreleasedBuffer':

GSObjCRuntime.m:1497: warning: `Class' may not respond to `+methodForSelector:' GSObjCRuntime.m:1497: warning: (Messages without a matching method signature GSObjCRuntime.m:1497: warning: will be assumed to return `id' and accept
  GSObjCRuntime.m:1497: warning: `...' as arguments.)
GSObjCRuntime.m:1497: warning: assignment from incompatible pointer type

(The "incompatible pointer type" warning is a direct consequence of not finding a suitable method in the first place.) There does exist an instance `-methodForSelector:' in the 'NSObject' class (which probably gets used in this case), but since Objective-C allows multiple root classes, the compiler cannot statically decide to focus on NSObject.
What should we do?  I see 3 choices:
(1) Leave things as they are. Users will be able to suppress the above warning by casting the receiver to the root class (in above case, '(NSObject *)'). (2) Build a list of all plausible root classes (i.e., classes without superclasses), and consult all instance methods for those classes when dispatching messages to
(3) Treat messages to 'Class' the same way we treat messages to 'id', i.e., consult all class and instance methods available. This is what the compiler appears to
      have done until now (in its mercurial and buggy way).

Personally, I like types (and compiler's warnings about them) :-), so I'd advocate we stick with (1), but we could also do (3). I'd really, really hate to have to implement (2), however.
Not only is it extra work, but it will adversely affect compile time.

Then, we have things like

GSCompatibility.m:696: warning: multiple methods named `-objectForKey:' found GSFileHandle.m:1245: warning: multiple methods named `-objectForKey:' found GSFileHandle.m:1294: warning: multiple methods named `-objectForKey:' found NSUserDefaults.m:791: warning: multiple methods named `-initWithPath:' found

where we're sending messages to receivers of type 'id'. In the majority of cases, the compiler is absolutely right to complain, and the receiver should be cast to a more specific type (and/or the corresponding method signatures should be cleaned up so that
they match up).  However, in a few cases we're dealing with the idiom

   [[ClassName alloc] init...]

in which case one _could_ make the argument that any method named 'alloc' should be treated specially by the compiler, i.e., as having a return type covariant with the receiver. What do you think? If we don't teach the compiler about 'alloc', then it is perfectly within its right to complain in this case also, unless we change foregoing to read

   [(ClassName *)[ClassName alloc] init...]

which, I must admit, does have a slighty redundant flavor to it. :-( Of course, the slippery slope argument applies here (if we treat 'alloc' specially, then what about

Finally, we have

GSXML.m:3765: warning: `GSXPathObject' may not respond to `+_newWithNativePointer:context:' NSDistantObject.m:110: warning: `GSDistantObjectPlaceHolder' may not respond to `+class' NSTimeZone.m:685: warning: `NSTimeZone' may not respond to `+arrayWithObject:'

all of which do seem reasonable to me, but please double-check.

Other than that, things look pretty good! Please take the objc-improvements-branch compiler for a spin one more time. I'd like to get this pushed into mainline 3.4 as soon as feasible, so that I
may embark on phase 2 of my project -- Objective-C++! :-)

Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

reply via email to

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