[Top][All Lists]

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

Re: New warnings (hopefully) in gcc 3.4

From: Fred Kiefer
Subject: Re: New warnings (hopefully) in gcc 3.4
Date: Mon, 01 Sep 2003 14:56:49 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021204

Alexander Malmberg wrote:
Recently, I've been working on cleaning up gcc's handling of method
prototypes, and how it selects one when sending a message. With a lot of
help from David Ayers, I now have a patched version that behaves the way
we think we want it to.

In addition to our artificial tests, I've tested by compiling GNUstep,
and in order to get some feedback on the new warnings, I've attached
logs of compiling -base and -gui with the new gcc. Since this may end up
affecting all objective-c code (including yours ;-), I'd appreciate
comments on:

* whether the new behavior (ie. actually code generated, not warnings)
is good. The only big difference from the current behavior is in the
case where the receiver is "typed" (ie. not 'id' or 'Class'), and a
method prototype could not be found in the type. Previous versions would
fall back to "no prototype", which means the return value was assumed to
be 'id' and the arguments passed as to a variadic function. The new
behavior is to search globally for a prototype before giving up, just as
for receivers of type 'id' or 'Class'.

* whether the new warnings are good. Some may be seen as a bit pedantic,
but I think they're acceptable (ie. sufficiently helpful to be worth the

* whether the wording of the new warnings is good. In particular, it's
important that the longer warnings about what gcc will do when it finds
no/several prototypes are clear.

In addition, we should clear up the issues indicated by the warnings.
Some are just minor typos or inconsistencies, or may require a cast so
that gcc can know for sure which prototype applies, but some indicate
serious problems.

I like what you did. At the start I thought the it is just reporting pedantic warnings, but than I could clearly see that there was an error in NSAttributedString that had been there unnoticed for months! Even one correctly reported error would make this change worthwhile. I will at once start to correct the reported problems in GUI.

But there is one case where the new behaviour is really unusable:

- (BOOL)readFromFile: (NSString *)fileName ofType: (NSString *)type
NSFileWrapper *wrapper = AUTORELEASE([[NSFileWrapper alloc] initWithPath: fileName]);
  return [self loadFileWrapperRepresentation: wrapper ofType: type];

Here we get a warning that initWithPath: is implemented with different return types. So what? We are creating a new object of class NSFileWrapper and that class has one specific implementation of this method. What I would like to see is a bit more knowledge about contexts. The method alloc has a return type of id, still we expect an object woth some resemblance of the class it gets send to.

Also it is sometimes confusing that GCC tries to filter out the possible different method types, so that only one of each type is shown, which most likely will not be the one that is actually meant.


reply via email to

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