[LLVMbugs] [Bug 19637] New: False-positive when pop_front from std::list<unique_ptr<T>> in C++11

[bugzilla-daemon at llvm.org]

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

            Bug ID: 19637
           Summary: False-positive when pop_front from
                    std::list<unique_ptr<T>>  in C++11
           Product: clang
           Version: 3.4
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: renauxthierry+llvmBugzilla at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following C++11 code is a minimal example of what I believe triggers a
false positive in the clang static analyzer:


*** begin code ***

#include <iostream>
#include <list>
#include <memory>

class ElementType {};

int main(int argc, const char * argv[]) {
    std::list<std::unique_ptr<ElementType>> theList(5);

    theList.pop_front();

    for (const auto &element: theList) { // (*)
        std::cout << "This should be fine." << std::endl;
    }

    return 0;
}

*** end code ***


On the line marked by an asterisk (*), the clang analyzer claims
".../main.cpp:21:29: Use of memory after it is freed (within a call to
'begin')"

As far as I see, this code is harmless. My guess is that the analyzer misses
the point that std::list<T>::pop_front() not only calls its elements'
destructor, but that it also moves the location of std::list<T>::begin().
Replacing the call to pop_front by pop_back makes the analyzer warning
disappear, and even replacing it by erase(theList.begin()) makes it come out
warning-free.

For reference: These results come from XCode 5.1.1 (5B1008) on Mac OS X 10.9.2,
clang --version "Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM
3.4svn)", "Target: x86_64-apple-darwin13.1.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/20140502/adfabf3f/attachment.html>