[LLVMbugs] [Bug 15649] New: clang-sa should warn when taking the address of __block storage?

[bugzilla-daemon at llvm.org]

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

            Bug ID: 15649
           Summary: clang-sa should warn when taking the address of
                    __block storage?
           Product: clang
           Version: 3.2
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: jim.correia at pobox.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10270
  --> http://llvm.org/bugs/attachment.cgi?id=10270&action=edit
sample code

Build and run the attached sample code.

-performTest1 works correctly when built with MRR. (Ignoring the possibility
that it won't if the autorelease pool implementation details of
NSFileCoordinator change.)

It doesn't work correctly when built for ARC. The reason is that the code
that the compiler generates (-performTest2 is written similarly to the what
the method looks like with the compiler generated code) overwrites the value
of error set in the block.

-performTest3 doesn't work correctly (either for MRR or ARC) because we take
the address of __block storage, then copy the block, moving that value to the
heap. We writing to the stale value on the stack.

These are really two separate issues, but both avoidable if clang-sa issued a
warning that taking the address of __block storage is likely going to lead to
heartache.

xcrun clang NSFileCoordinatorErrorPattern.m -fobjc-arc -framework Foundation 

xcrun clang --version

    Apple LLVM version 4.2 (clang-425.0.27) (based on LLVM 3.2svn)
    Target: x86_64-apple-darwin12.3.0
    Thread model: posix

-- 
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/20130401/c429852d/attachment.html>