dexonsmith added inline comments.

================
Comment at: clang/test/CodeGen/union-tail-padding.c:28-36
+union Front {
+  int i;
+  long long ll;
+};
+
+union Front front1;
+union Front front2 = {};        // expected-warning {{Initializing union 
'Front' field 'i' only initializes the first 4 of 8 bytes, leaving the 
remaining 4 bytes undefined}}
----------------
jfb wrote:
> dexonsmith wrote:
> > jfb wrote:
> > > dexonsmith wrote:
> > > > Are these warnings actionable?  What should users do when they see this 
> > > > warning?
> > > Good point!
> > > 
> > > I was thinking about this, and was wondering if I should add a fixit 
> > > which suggests using the first wider member of the union. The problem is 
> > > to offer the same object representation... that's tricky on its own 
> > > (there isn't always an exact match), and then we have to deal with type 
> > > punning (in C++, not in C).
> > > 
> > > So I'd love ideas, because I'm not sure what to do. That being said, I 
> > > wrote this partly because D68115 was surprising to folks, and partly 
> > > because developers would like to opt-in to this diagnostic to find places 
> > > where initialization isn't doing what they think.
> > > 
> > > Maybe instead we should suggest to leave uninitialized, and use an 
> > > assignment, or `memset`?
> > > Maybe instead we should suggest to leave uninitialized, and use an 
> > > assignment, or `memset`?
> > 
> > It's not clear to me that those are better.  For example, `memset` doesn't 
> > seem right for non-PODs in C++.  I'm not sure what to suggest though.
> I'd argue that non-PODs in unions don't seem right either ;-)
> It would be easy to diagnose non-trivially-copyable types differently in this 
> circumstance.
> It would be easy to diagnose non-trivially-copyable types differently in this 
> circumstance.

Good point.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80055/new/

https://reviews.llvm.org/D80055



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to