[cfe-dev] Unions in the Clang Static Analyzer

[Keno Fischer via cfe-dev]

Sorry for bumping an old thread, but I ended up trying to pick up the
project that brought this up again after
giving up last year because of the analyzer's lacking union support.
Naturally I ran into the same problems again :/.
It seems like the first step here is to decide what model of unions the
analyzer intends to support. I'd be
happy to try fix some things here, but of course those decisions need to be
made first.

On Fri, Mar 3, 2017 at 2:12 AM, Aaron Ballman <aaron at aaronballman.com>
wrote:

> On Thu, Mar 2, 2017 at 8:54 PM, Keno Fischer <keno at juliacomputing.com>
> wrote:
> > This behavior also differs between C and C++. For example, C has
> explicitly:
> >
> > [N1570, Footnote 95]
> > If the member used to read the contents of a union object is not the
> > same as the member last used to store a value in the object, the
> > appropriate part of the object representation of the value is
> > reinterpreted as an object representation in the new type as described
> > in 6.2.6 (a process sometimes called ‘‘type punning’’). This might be
> > a trap representation.
> >
> > where object representation is essentially what you'd get if you
> > memcpyed the value.
>
> Yes, if everything lines up just perfectly, then in C this may be
> okay. I say may because it can still be a trap representation, it
> could be a misaligned access, there could be unspecified values within
> the union member, etc (so it depends on the types and the specific
> values), so it is *not* strictly a safe operation to do in C either.
>
> ~Aaron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180819/b2d9325f/attachment.html>