[llvm-bugs] [Bug 37237] New: Rejects valid with _Atomic void

[via llvm-bugs]

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

            Bug ID: 37237
           Summary: Rejects valid with _Atomic void
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: aaron at aaronballman.com
                CC: llvm-bugs at lists.llvm.org

C does not disallow void types from having the _Atomic qualifier.

C17 6.7.3p4:
The type modified by the _Atomic qualifier shall not be an array type or a
function type.

A void type is neither an array type nor a function type, thus void is allowed
to be qualified. This turns out to be useful for people who want to write
generic C code like: void f(_Atomic void *ptr);

We currently diagnose this because the C standard is not clear whether the
_Atomic qualifier requires a complete type, so this is currently a purposeful
diagnosis. However, when this topic came up in the context of WG14 N2209
(atomic pointers in expressions) the paper noted that Clang was the only
implementation that seems to diagnose the construct. Further, it seems to be a
generally useful construct outside of void, such as:

// Header file
struct S;
void f(_Atomic struct S *ptr);

// Implementation file
struct S { int a, b; };
void f(_Atomic struct S *ptr) {
  // Stuff
}

Given that the standard does not explicitly state that the qualified type must
be complete, I don't think we should require it. This keeps _Atomic the same as
const and volatile in that regard and aligns with how I interpret the feeling
in the room at WG14 in Brno.

-- 
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/20180425/8a0266c9/attachment.html>