Unions in the Clang Static Analyzer

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Unions in the Clang Static Analyzer

Robinson, Paul via cfe-dev
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.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unions in the Clang Static Analyzer

Robinson, Paul via cfe-dev
Hello,

I'm not aware of any unfinished work on union support. I'd gladly give a few hints.

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.

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 http://lists.llvm.org/pipermail/cfe-dev/2017-February/052769.html .

Then, unions are even more fun because they challenge the concept of SymbolRegionValue, which is a very basic thing. Consider an example:

  union U { intptr_t x; void *p; }

  void foo(union U u) {
    intptr_t X = u.x; // reg_$0<u.x>
    void *P = u.p; // &SymRegion{reg_$1<u.p>}
    if (X == P) { ... }
  }

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?

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.


02/03/2017 1:53 AM, Keno Fischer via cfe-dev wrote:
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.


_______________________________________________ cfe-dev mailing list [hidden email] http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unions in the Clang Static Analyzer

Robinson, Paul via cfe-dev
On Thu, Mar 2, 2017 at 12:12 PM, Artem Dergachev <[hidden email]> wrote:
> 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?

My rough conception on how this would work is that the first access
would create the symbol and determine the type and then accesses
through other members would be equivalent to a cast to the other type.

At the very least, I would like to make sure that symbols are
preserved through union assignment (and passing unions to functions),
if they are only every accessed through the same union member, as well
as simple cases like:

union {
int *intptr;
float *floatptr;
}

Just having that work reliably would probably have fixed 90% of the
trouble I was having here.

Keno
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unions in the Clang Static Analyzer

Robinson, Paul via cfe-dev
In reply to this post by Robinson, Paul via cfe-dev
Hi all,

There is one thing that can make the implementation a bit easier :)
The reading of a union field that was not stored last may cause undefined behavior. A discussion on this issue can be found on
https://www.securecoding.cert.org/confluence/display/c/EXP39-C.+Do+not+access+a+variable+through+a+pointer+of+an+incompatible+type

I guess we need some language lawyers here. Aaron, can I disturb you?


02.03.2017 20:12, Artem Dergachev via cfe-dev пишет:
Hello,

I'm not aware of any unfinished work on union support. I'd gladly give a few hints.

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.

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 http://lists.llvm.org/pipermail/cfe-dev/2017-February/052769.html .

Then, unions are even more fun because they challenge the concept of SymbolRegionValue, which is a very basic thing. Consider an example:

  union U { intptr_t x; void *p; }

  void foo(union U u) {
    intptr_t X = u.x; // reg_$0<u.x>
    void *P = u.p; // &SymRegion{reg_$1<u.p>}
    if (X == P) { ... }
  }

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?

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.


02/03/2017 1:53 AM, Keno Fischer via cfe-dev wrote:
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.


_______________________________________________ cfe-dev mailing list [hidden email] http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unions in the Clang Static Analyzer

Robinson, Paul via cfe-dev
On Thu, Mar 2, 2017 at 1:11 PM, Alexey Sidorin <[hidden email]> wrote:
> Hi all,
>
> There is one thing that can make the implementation a bit easier :)
> The reading of a union field that was not stored last may cause undefined
> behavior. A discussion on this issue can be found on
> https://www.securecoding.cert.org/confluence/display/c/EXP39-C.+Do+not+access+a+variable+through+a+pointer+of+an+incompatible+type
>
> I guess we need some language lawyers here. Aaron, can I disturb you?

Certainly -- is there advice in particular you're looking for? I'm not
overly familiar with the static analyzer design, but I'm to help as I
can.

A note below...

>
>
> 02.03.2017 20:12, Artem Dergachev via cfe-dev пишет:
>
> Hello,
>
> I'm not aware of any unfinished work on union support. I'd gladly give a few
> hints.
>
> 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.
>
> 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
> http://lists.llvm.org/pipermail/cfe-dev/2017-February/052769.html .
>
> Then, unions are even more fun because they challenge the concept of
> SymbolRegionValue, which is a very basic thing. Consider an example:
>
>   union U { intptr_t x; void *p; }
>
>   void foo(union U u) {
>     intptr_t X = u.x; // reg_$0<u.x>
>     void *P = u.p; // &SymRegion{reg_$1<u.p>}
>     if (X == P) { ... }
>   }
>
> 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.

They do not represent the same thing -- they designate the same region
of storage, but the underlying objects are not "the same" because they
have independent lifetimes. A union member within its lifetime is
"active", and the static analyzer would need to track which member of
the union is active to be able to reason about the program
appropriately.

~Aaron

> 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?
>
> 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.
>
>
> 02/03/2017 1:53 AM, Keno Fischer via cfe-dev wrote:
>
> 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.
>
>
> _______________________________________________ cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unions in the Clang Static Analyzer

Robinson, Paul via cfe-dev
Hi Aaron!

Thank you for response. I'm curious if such cases like described:

   union U { intptr_t x; void *p; }

   void foo(union U u) {
     intptr_t X = u.x; // reg_$0<u.x>
     void *P = u.p; // &SymRegion{reg_$1<u.p>}
     if (X == P) { ... }
   }

have defined behavior or not. I have seen many discussions on this but I
haven't seen any strict rule on this.


03.03.2017 08:49, Aaron Ballman пишет:

> On Thu, Mar 2, 2017 at 1:11 PM, Alexey Sidorin <[hidden email]> wrote:
>> Hi all,
>>
>> There is one thing that can make the implementation a bit easier :)
>> The reading of a union field that was not stored last may cause undefined
>> behavior. A discussion on this issue can be found on
>> https://www.securecoding.cert.org/confluence/display/c/EXP39-C.+Do+not+access+a+variable+through+a+pointer+of+an+incompatible+type
>>
>> I guess we need some language lawyers here. Aaron, can I disturb you?
> Certainly -- is there advice in particular you're looking for? I'm not
> overly familiar with the static analyzer design, but I'm to help as I
> can.
>
> A note below...
>
>>
>> 02.03.2017 20:12, Artem Dergachev via cfe-dev пишет:
>>
>> Hello,
>>
>> I'm not aware of any unfinished work on union support. I'd gladly give a few
>> hints.
>>
>> 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.
>>
>> 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
>> http://lists.llvm.org/pipermail/cfe-dev/2017-February/052769.html .
>>
>> Then, unions are even more fun because they challenge the concept of
>> SymbolRegionValue, which is a very basic thing. Consider an example:
>>
>>    union U { intptr_t x; void *p; }
>>
>>    void foo(union U u) {
>>      intptr_t X = u.x; // reg_$0<u.x>
>>      void *P = u.p; // &SymRegion{reg_$1<u.p>}
>>      if (X == P) { ... }
>>    }
>>
>> 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.
> They do not represent the same thing -- they designate the same region
> of storage, but the underlying objects are not "the same" because they
> have independent lifetimes. A union member within its lifetime is
> "active", and the static analyzer would need to track which member of
> the union is active to be able to reason about the program
> appropriately.
>
> ~Aaron
>
>> 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?
>>
>> 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.
>>
>>
>> 02/03/2017 1:53 AM, Keno Fischer via cfe-dev wrote:
>>
>> 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.
>>
>>
>> _______________________________________________ cfe-dev mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unions in the Clang Static Analyzer

Robinson, Paul via cfe-dev
On Thu, Mar 2, 2017 at 8:16 PM, Alexey Sidorin <[hidden email]> wrote:
> Hi Aaron!
>
> Thank you for response. I'm curious if such cases like described:
>
>   union U { intptr_t x; void *p; }
>
>   void foo(union U u) {
>     intptr_t X = u.x; // reg_$0<u.x>

This could be undefined behavior if, prior to calling foo(), u.x was
not the active union member or if there was no active union member.

>     void *P = u.p; // &SymRegion{reg_$1<u.p>}

Assuming there was not already UB, this has undefined behavior because
the lifetime of u.p has not begun (despite some compilers supporting,
and even documenting, this undefined behavior by allowing the
expression to act as a duck-type cast, which is a perfectly acceptable
form of undefined behavior).

>     if (X == P) { ... }
>   }
>
> have defined behavior or not. I have seen many discussions on this but I
> haven't seen any strict rule on this.

The strict rules on it are in [class.union] and [basic.life]p1 (to get started).

~Aaron

>
>
> 03.03.2017 08:49, Aaron Ballman пишет:
>
>> On Thu, Mar 2, 2017 at 1:11 PM, Alexey Sidorin <[hidden email]>
>> wrote:
>>>
>>> Hi all,
>>>
>>> There is one thing that can make the implementation a bit easier :)
>>> The reading of a union field that was not stored last may cause undefined
>>> behavior. A discussion on this issue can be found on
>>>
>>> https://www.securecoding.cert.org/confluence/display/c/EXP39-C.+Do+not+access+a+variable+through+a+pointer+of+an+incompatible+type
>>>
>>> I guess we need some language lawyers here. Aaron, can I disturb you?
>>
>> Certainly -- is there advice in particular you're looking for? I'm not
>> overly familiar with the static analyzer design, but I'm to help as I
>> can.
>>
>> A note below...
>>
>>>
>>> 02.03.2017 20:12, Artem Dergachev via cfe-dev пишет:
>>>
>>> Hello,
>>>
>>> I'm not aware of any unfinished work on union support. I'd gladly give a
>>> few
>>> hints.
>>>
>>> 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.
>>>
>>> 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
>>> http://lists.llvm.org/pipermail/cfe-dev/2017-February/052769.html .
>>>
>>> Then, unions are even more fun because they challenge the concept of
>>> SymbolRegionValue, which is a very basic thing. Consider an example:
>>>
>>>    union U { intptr_t x; void *p; }
>>>
>>>    void foo(union U u) {
>>>      intptr_t X = u.x; // reg_$0<u.x>
>>>      void *P = u.p; // &SymRegion{reg_$1<u.p>}
>>>      if (X == P) { ... }
>>>    }
>>>
>>> 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.
>>
>> They do not represent the same thing -- they designate the same region
>> of storage, but the underlying objects are not "the same" because they
>> have independent lifetimes. A union member within its lifetime is
>> "active", and the static analyzer would need to track which member of
>> the union is active to be able to reason about the program
>> appropriately.
>>
>> ~Aaron
>>
>>> 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?
>>>
>>> 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.
>>>
>>>
>>> 02/03/2017 1:53 AM, Keno Fischer via cfe-dev wrote:
>>>
>>> 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.
>>>
>>>
>>> _______________________________________________ cfe-dev mailing list
>>> [hidden email]
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> [hidden email]
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>>
>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unions in the Clang Static Analyzer

Robinson, Paul via cfe-dev
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.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unions in the Clang Static Analyzer

Robinson, Paul via cfe-dev
On Thu, Mar 2, 2017 at 8:54 PM, Keno Fischer <[hidden email]> 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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...