[LLVMbugs] [Bug 15725] New: uninitialized __block storage variables used in blocks don't provoke warning

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=15725

            Bug ID: 15725
           Summary: uninitialized __block storage variables used in blocks
                    don't provoke warning
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: tjw at me.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10337
  --> http://llvm.org/bugs/attachment.cgi?id=10337&action=edit
test case

See the attached test case, in which a __block variable is left uninitialized
and then used w/in a block:


void test0(void)
{
    __block int x; // BAD: No warning that this is the uninitialized variable

    void (^block)(void) = ^{ // BAD: No warning that an uninitialized variable
is captured
        printf("x = %d\n", x);
    };
    block();
}

This is conceivably good in the case that the block variable is out-only (the
block initializes it), but a very common pattern with Foundation is now:

__block BOOL success = NO;
__block NSError *error;
[coordinator coordinate... ^(NSURL *newURL){
   ... do a bunch of stuff that might fail ...
   success = YES;
}];
if (!success) {
  ... handle the error ...
}

In the case that you forget the 'NO' initializer above, you'll miss your error
handling case with disastrous results.

This is especially insidious in ARC mode where you get trained to not
initialize locals (since ARC initializes object pointer locals to nil for you).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130411/f9ba2545/attachment.html>