Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assigning to self twice in init provokes spurious warning about not assigning at all #9466

Closed
llvmbot opened this issue Jan 28, 2011 · 5 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla clang:static analyzer

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Jan 28, 2011

Bugzilla Link 9094
Resolution FIXED
Resolved on Feb 04, 2011 23:57
Version trunk
OS MacOS X
Attachments example
Reporter LLVM Bugzilla Contributor
CC @akyrtzi,@tkremenek

Extended Description

A common pattern in classes with multiple initializers (for example NSView with -initWithFrame: and -initWithCoder:) is to put the subclass's common initialization bits into a static function. If you structure this so that the common init can fail and return nil, then you can end up with something like this:

  • init;
    {
    if (!(self = [super init]))
    return nil;
    if (!(self = _commonInit(self)))
    return nil;

    return self;
    }

This provokes a warning about never having assigned self before returning it, which is not true:

double-assign-self.m:28:5: warning: Returning 'self' before setting it to the result of '[(super or self) init...]'

@llvmbot
Copy link
Collaborator Author

llvmbot commented Jan 28, 2011

assigned to @tkremenek

@tkremenek
Copy link
Contributor

cloned to rdar://problem/8937441

@akyrtzi
Copy link
Contributor

akyrtzi commented Jan 31, 2011

Two issues I see:

  1. The message should change to "Returning 'self' while it is not set to the
    result of '[(super or self) init...]'" to make it more clear why the warning is emitted.
  2. Should whitelist function calls as valid initialization for self.

I'll investigate 2) to see its effect (whether it will hide actual bugs).

Any thoughts about the above ?

@tkremenek
Copy link
Contributor

I'll investigate 2) to see its effect (whether it will hide actual bugs).

I think (2) should only apply after the super class bits have been initialized.

@akyrtzi
Copy link
Contributor

akyrtzi commented Feb 5, 2011

Fixed at r124940. Thanks for the report!

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla clang:static analyzer
Projects
None yet
Development

No branches or pull requests

3 participants