[llvm-bugs] [Bug 32427] New: Clang should warn for not initializing field in a move constructor

via llvm-bugs llvm-bugs at lists.llvm.org
Sun Mar 26 19:12:05 PDT 2017


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

            Bug ID: 32427
           Summary: Clang should warn for not initializing field in a move
                    constructor
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: hughbellars at gmail.com
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org

The C++ standard states that a move constructor is called when returning a
value from a method unless the compiler is able to elide the move,

For example, the following code invokes undefined behaviour:

#include <iostream>

class CallEmission {
public:
    bool assumedPlusZeroSelf;
    CallEmission(bool assumedPlusZeroSelf) :
assumedPlusZeroSelf(assumedPlusZeroSelf) {}

    CallEmission(CallEmission &&e) {
        std::cout << "Called move constructor" << "\n";
    }
};

CallEmission method() {
    CallEmission x(false);
    return x;
}

int main() {
    CallEmission x = method();
    std::cout << x.assumedPlusZeroSelf;
}

MSVC:
> Called move constructor
> 140

Clang:
> 0

This is because with MSVC the move constructor is called, which fails to
initialize the memory of `assumedPlusZeroSelf`.

This caused a crash in Swift on Windows with MSVC
(https://github.com/apple/swift/pull/8337)

Michael Gottesman, an engineer on the Swift team said "@hughbe Nice find! I
wonder if there is a warning for this.". Seemingly there is not, so it would be
nice to issue a warning here to prevent different behaviour on different
compilers.

Maybe something like "field assumedPlusZeroSelf is not initialized in
constructor CallEmission(CallEmission&&)"

-- 
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/20170327/2fe65615/attachment.html>


More information about the llvm-bugs mailing list