[LLVMbugs] [Bug 23899] New: -Wbraced-scalar-init should explain the ATOMIC_FLAG_INIT rule if applicable

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Jun 19 14:58:03 PDT 2015


https://llvm.org/bugs/show_bug.cgi?id=23899

            Bug ID: 23899
           Summary: -Wbraced-scalar-init should explain the
                    ATOMIC_FLAG_INIT rule if applicable
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++14
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

-Wbraced-scalar-init will (correctly!) warn on the following code:

class X {
  std::atomic_flag f;
  X() : f(ATOMIC_FLAG_INIT) {}  // Invalid!
  X() : f{ATOMIC_FLAG_INIT} {}  // Also invalid!
};

because ATOMIC_FLAG_INIT is usually #define'd to {0}. Unfortunately, it doesn't
explain why this is a problem.

C++14 [atomics.flag]/4 states this:

  "The macro ATOMIC_FLAG_INIT shall be defined in such a way that it can be
used to initialize an object of type atomic_flag to the clear state. The macro
can be used in the form:

  "atomic_flag guard = ATOMIC_FLAG_INIT;

  "It is unspecified whether the macro can be used in other initialization
contexts."

The way to initialize the atomic flag is "std::atomic_flag f =
ATOMIC_FLAG_INIT;". That exact syntax, only.

Frankly, Wbraced-scalar-init picks this up by accident. A happy accident. But
since we're here, we should detect the attempt to initialize a std::atomic_flag
with ATOMIC_FLAG_INIT in any means except the one permitted syntax above. Tell
the user that they need to use an in-class initializer, instead of complaining
about extra braces.

-- 
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/20150619/7c02b9f6/attachment.html>


More information about the llvm-bugs mailing list