<div dir="ltr"><div>Hi!</div><div><br></div><div>Just brainstorming a bit, some of these might make no sense:</div><div>* We could find the discriminators using name conventions just as Kristóf mentioned</div><div>* We could have annotations, but people usually do not like this approach<br></div><div>* Maybe those classes have separate constructors for each of the type in the union? We could have some suppression heuristics around that:</div><div>  - If we have multiple constructors only report fields that is uninitialized in all of them? This might also give us a lot of false negatives and hard to implement<br></div><div>  - If the reads of a field is usually behind a guard do not report it as uninitialized</div><div>  - Only check fields that can be unconditionally accessed via the public interface, might be fooled by castAs like methods</div><div>* Suppress reports from classes with most of their fields being uninitialized. This is a threshold kind of thing that is unpopular to some since some could could bounce back and forth around the threshold.</div><div>* Option to only care about fields that are initialized on some paths and not initialized on others? <br></div><div><br></div><div>Whichever direction we go, in case the heuristics might also result in some false positives, it might be good idea to make it optional (but on by default).</div><div><br></div><div>Regards,</div><div>Gabor<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 13 Aug 2018 at 11:31, Kristóf Umann via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Hi!<div dir="auto"><br></div><div dir="auto">Thank you so much for this! I'm very grateful for all the reviews and feedback I've been given, makes my work so much more enjoyable.</div><div dir="auto"><br></div><div dir="auto">I'm aware of this issue, LLVM/Clang is littered with these constructs. I haven't tried to fix it just yet. Maybe add a heuristic that fields/types with "Kind" or "Tag" substring in them should be ignored?</div><div dir="auto"><br></div><div dir="auto">Best regards,</div><div dir="auto">Kristóf Umann</div><div dir="auto"><br></div><div dir="auto">(Btw my first name is Kristóf, it's quite confusing in hungarian)</div><br><div class="gmail_extra"><br><div class="gmail_quote">On 13 Aug 2018 20:15, "George Karpenkov" <<a href="mailto:ekarpenkov@apple.com" target="_blank">ekarpenkov@apple.com</a>> wrote:<br type="attribution"><blockquote class="m_5617950693537870137quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I have recently evaluated the  (relatively recently developed, available with -Xclang -analyzer-checker=alpha.cplusplus.UninitializedObject)<br>
UninitializedObjectChecker, which warns after the constructor call if any of the fields were left uninitialized.<br>
<br>
Good news: I have found a few actual bugs<br>
Bad news: Those bugs were hidden under hundreds of other reports<br>
<br>
Most of the false alarms come from a case where a class is actually used as a union,<br>
and a field is used to differentiate between those types.<br>
Then unused types are simply left uninitialized.<br>
Conceptually, this is not a correct design, but nevertheless, it is rather ubiquitous.<br>
<br>
I have no idea whether we can work around this case, @Umann, any ideas there?<br>
<font color="#888888"><br>
George<br>
</font></blockquote></div><br></div></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>