[PATCH] D62988: Add an attribute to allow fields of non-trivial types in C unions

rjmccall added a comment. In D62988#1537401 , @ahatanak wrote: > In D62988#1537082 , @rjmccall wrote: > > > Does this lead to C/C++ ABI mismatches? Should we just honor this in C++ > > as well by ignoring it when

[PATCH] D62988: Add an attribute to allow fields of non-trivial types in C unions

rsmith added a comment. How do you write correct (non-leaking, non-double-freeing, non-releasing-invalid-pointers) code with this attribute? For example, suppose I have a `__strong` union member: does storing to it release the old value (which might be a different union member)? If so, how do y

[PATCH] D62988: Add an attribute to allow fields of non-trivial types in C unions

ahatanak added a comment. In D62988#1538577 , @rsmith wrote: > How do you write correct (non-leaking, non-double-freeing, > non-releasing-invalid-pointers) code with this attribute? For example, > suppose I have a `__strong` union member: does storing to

[PATCH] D62988: Add an attribute to allow fields of non-trivial types in C unions

rsmith added a comment. In D62988#1539230 , @ahatanak wrote: > In D62988#1538577 , @rsmith wrote: > > > How do you write correct (non-leaking, non-double-freeing, > > non-releasing-invalid-pointers) code with this

[PATCH] D62988: Add an attribute to allow fields of non-trivial types in C unions

rjmccall added a comment. For ARC, you could bzero the union member; this is what how we tell people to initialize malloc'ed memory as well, since there's no default-constructor concept that they can invoke for such cases. Our immediate need for this attribute is that we have some code that wan

[PATCH] D62988: Add an attribute to allow fields of non-trivial types in C unions

rsmith added a comment. In D62988#1540359 , @rjmccall wrote: > For ARC, you could bzero the union member; this is what how we tell people to > initialize malloc'ed memory as well, since there's no default-constructor > concept that they can invoke for su

[PATCH] D62988: Add an attribute to allow fields of non-trivial types in C unions

ahatanak added a comment. John and I had a discussion offline and decided that we should not pursue the approach taken in this patch. I'll try to work on a patch that follows the C++11 approach when I have time later. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org

[PATCH] D62988: Add an attribute to allow fields of non-trivial types in C unions

ahatanak created this revision. ahatanak added a reviewer: rjmccall. ahatanak added a project: clang. Herald added subscribers: dexonsmith, jkorous. clang currently disallows fields of non-trivial types (e.g., `__strong`) in unions in C mode since it's not possible for the compiler to determine h

[PATCH] D62988: Add an attribute to allow fields of non-trivial types in C unions

rjmccall added a reviewer: rsmith. rjmccall added a comment. Does this lead to C/C++ ABI mismatches? Should we just honor this in C++ as well by ignoring it when deciding to delete special members? Is taking such a general name a good idea if it's language-specific? Richard, thoughts? Repos

[PATCH] D62988: Add an attribute to allow fields of non-trivial types in C unions

ahatanak added a comment. In D62988#1537082 , @rjmccall wrote: > Does this lead to C/C++ ABI mismatches? Should we just honor this in C++ as > well by ignoring it when deciding to delete special members? Is taking such > a general name a good idea if i