[Top][All Lists]

[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*) initWithPath: (NSString*)aPath;

- (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

- Alexander Malmberg

reply via email to

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