<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
I'm not aware of any unfinished work on union support. I'd gladly
give a few hints.<br>
<br>
RegionStore itself already operates in a union-friendly manner: even
though it presents itself as a MemRegion->SVal map, internally it
only stores base regions and byte offsets as keys, regardless of how
the bytes stored are interpreted.<br>
<br>
However, i suspect bigger problems with actually representing
symbolic values for fields that are interpreted in multiple ways
during the analysis. First of all, reinterpret-casts of basic types
are in general modeled poorly. For example, cast from pointer to
integer is represented as a special LocAsInteger SVal sub-class,
support for which in SValBuilder is worse than for symbols; at the
same time cast from integer to pointer is not represented at all, as
i mentioned recently in
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/pipermail/cfe-dev/2017-February/052769.html">http://lists.llvm.org/pipermail/cfe-dev/2017-February/052769.html</a> .<br>
<br>
Then, unions are even more fun because they challenge the concept of
SymbolRegionValue, which is a very basic thing. Consider an example:<br>
<br>
union U { intptr_t x; void *p; }<br>
<br>
void foo(union U u) {<br>
intptr_t X = u.x; // reg_$0<u.x><br>
void *P = u.p; // &SymRegion{reg_$1<u.p>}<br>
if (X == P) { ... }<br>
}<br>
<br>
The symbolic values for X and P look completely different, the worst
thing here probably being that X is NonLoc while P is Loc. Yet, they
represent the same thing. How would we unify these values? If you
come up with a single symbol to represent them, what would be the
type of that symbol? Or would you prefer to constrain these symbols
to be equal, and rely on the constraint solver to figure things out?<br>
<br>
So making a proper union support is going to be a fun research
project. Smaller incremental improvements that fix particular cases
you encounter are also very much welcome. There's not necessarily
much thought behind the safety-first bail-outs, so if you are seeing
significant improvements by removing them, we could consider lifting
them; it may also turn out that they're necessary, and an
experienced eye may sometimes understand why, but as long as there
is no comprehensive explanation in comments and no testcase
coverage, i'd rather encourage you to remove them and see what
happens; especially considering that you've got access to a good
codebase to test these changes upon.<br>
<br>
<br>
<div class="moz-cite-prefix">02/03/2017 1:53 AM, Keno Fischer via
cfe-dev wrote:<br>
</div>
<blockquote
cite="mid:CABV8kRx2zsS3ndhJ=STERAvSss=B4tqKJmi8uAeEzL=DL=_cGA@mail.gmail.com"
type="cite">
<div dir="auto">I was having some trouble with using the static
analyzer on code that involves unions. Looking through the code,
it seems like this is a known problem and unions aren't
particularly well supported. Personally, I was able to make some
progress by just ripping out all the checks for union types,
particularly in RegionStore. However, that's obviously a hacky
solution, so to ensure that my check will keep working, I'd like
to improve upstream support for unions if possible. Has anybody
thought about this problem before/is there already a design for
this? Alternatively, have people collected test cases that would
benefit from improving union support? I'm sure I'm not the first
person to hit this issue, so I'd appreciate any pointers to
prior work.</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
<br>
</blockquote>
<br>
</body>
</html>