<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Annotations IMO definitely make no sense here, as it seems the design pattern is already bad:<div class="">either a subclass or a proper union should be used instead.</div><div class=""><br class=""></div><div class="">Perhaps it’s possible to try to heuristically determine that based on naming conventions of fields indeed.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 13, 2018, at 4:24 PM, Gábor Horváth <<a href="mailto:xazax.hun@gmail.com" class="">xazax.hun@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi!</div><div class=""><br class=""></div><div class="">Just brainstorming a bit, some of these might make no sense:</div><div class="">* We could find the discriminators using name conventions just as Kristóf mentioned</div><div class="">* We could have annotations, but people usually do not like this approach<br class=""></div><div class="">* Maybe those classes have separate constructors for each of the type in the union? We could have some suppression heuristics around that:</div><div class="">  - 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 class=""></div><div class="">  - If the reads of a field is usually behind a guard do not report it as uninitialized</div><div class="">  - Only check fields that can be unconditionally accessed via the public interface, might be fooled by castAs like methods</div><div class="">* 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 class="">* Option to only care about fields that are initialized on some paths and not initialized on others? <br class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Regards,</div><div class="">Gabor<br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, 13 Aug 2018 at 11:31, Kristóf Umann via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class="">Hi!<div dir="auto" class=""><br class=""></div><div dir="auto" class="">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" class=""><br class=""></div><div dir="auto" class="">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" class=""><br class=""></div><div dir="auto" class="">Best regards,</div><div dir="auto" class="">Kristóf Umann</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">(Btw my first name is Kristóf, it's quite confusing in hungarian)</div><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On 13 Aug 2018 20:15, "George Karpenkov" <<a href="mailto:ekarpenkov@apple.com" target="_blank" class="">ekarpenkov@apple.com</a>> wrote:<br type="attribution" class=""><blockquote class="m_5617950693537870137quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="">
<br class="">
I have recently evaluated the  (relatively recently developed, available with -Xclang -analyzer-checker=alpha.cplusplus.UninitializedObject)<br class="">
UninitializedObjectChecker, which warns after the constructor call if any of the fields were left uninitialized.<br class="">
<br class="">
Good news: I have found a few actual bugs<br class="">
Bad news: Those bugs were hidden under hundreds of other reports<br class="">
<br class="">
Most of the false alarms come from a case where a class is actually used as a union,<br class="">
and a field is used to differentiate between those types.<br class="">
Then unused types are simply left uninitialized.<br class="">
Conceptually, this is not a correct design, but nevertheless, it is rather ubiquitous.<br class="">
<br class="">
I have no idea whether we can work around this case, @Umann, any ideas there?<br class="">
<font color="#888888" class=""><br class="">
George<br class="">
</font></blockquote></div><br class=""></div></div></div>
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>