You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The exact validity rules of unions are unsettled. However, we can support unions by implementing both the most permissive and most restrictive possibilities, depending on whether the union appears in source or destination position.
At minimum, a union's bit-validity must accept all instances assignable by field writes. For example, this union:
...must accept both 0x01 and 0x02 as bit valid instances, because baz.a = Foo::A and baz.b = Bar::B can be written in safe code today. In other words, the bit-validity of a union is at least the union of the validity of its variants.
Complicating matters, union variants may be partially initialized. For example:
Now, baz's bits do not correspond, wholly, to either variant a or variant b, but rather a mix. In other words, the bit-validity of a union is at least the set of all bit validities possible through recursive field assignment.
On the other hand, it might be decided that all unions implicitly admit initialized bytes. If this is the case, we will need to treat all unions as bags of uninitialized bytes.
Until this is decided, we can't pick any definition in all cases. If TransmuteFrom treats unions as always implicitly admitting uninit, then it will accept transmutations whose soundness might change out from under us.
I think we can work around this by using the permissive bit-validity possibility for unions appearing in source position, and a more restrictive version for unions appearing in destination position.
The text was updated successfully, but these errors were encountered:
jswrenn
changed the title
Union transmutes should be variance-aware
Union transmutes should be "variance"-aware
Sep 14, 2024
The exact validity rules of unions are unsettled. However, we can support unions by implementing both the most permissive and most restrictive possibilities, depending on whether the union appears in source or destination position.
At minimum, a union's bit-validity must accept all instances assignable by field writes. For example, this union:
...must accept both
0x01
and0x02
as bit valid instances, becausebaz.a = Foo::A
andbaz.b = Bar::B
can be written in safe code today. In other words, the bit-validity of a union is at least the union of the validity of its variants.Complicating matters, union variants may be partially initialized. For example:
Now,
baz
's bits do not correspond, wholly, to either varianta
or variantb
, but rather a mix. In other words, the bit-validity of a union is at least the set of all bit validities possible through recursive field assignment.On the other hand, it might be decided that all unions implicitly admit initialized bytes. If this is the case, we will need to treat all unions as bags of uninitialized bytes.
Until this is decided, we can't pick any definition in all cases. If
TransmuteFrom
treats unions as always implicitly admitting uninit, then it will accept transmutations whose soundness might change out from under us.I think we can work around this by using the permissive bit-validity possibility for unions appearing in source position, and a more restrictive version for unions appearing in destination position.
The text was updated successfully, but these errors were encountered: