[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New warnings (hopefully) in gcc 3.4
From: |
Alexander Malmberg |
Subject: |
Re: New warnings (hopefully) in gcc 3.4 |
Date: |
Tue, 02 Sep 2003 01:46:54 +0200 |
Fred Kiefer wrote:
> 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.
But gcc doesn't know that. All it has is the prototype: +(id)alloc, and
all it deals with is the language, not conventions in libraries built on
the language. I don't think that tying the behavior of the language to
the conventions of any particular library/interface is appropriate.
In this case, I think it's just a matter of NSDistributedLock not
following the conventions we have. Grepping through base and gui shows
that there are only two -init* methods that don't return id:
NSDistributedLock.h:
- (NSDistributedLock*) initWithPath: (NSString*)aPath;
NSWindow.h:
- (NSWindow *) initWithWindowRef: (void *)windowRef;
so I think these should be fixed to return id.
> 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.
I'm afraid I don't understand what you mean here. Could you give an
example?
- Alexander Malmberg
Re: New warnings (hopefully) in gcc 3.4, Fred Kiefer, 2003/09/01
Re: New warnings (hopefully) in gcc 3.4, David Ayers, 2003/09/01
Re: New warnings (hopefully) in gcc 3.4, Nicola Pero, 2003/09/01