Stream: t-lang/wg-unsafe-code-guidelines

Topic: #84


gnzlbg (Feb 06 2019 at 12:48, on Zulip):

@RalfJ I am not 100% sure what's happening in those examples.

gnzlbg (Feb 06 2019 at 12:49, on Zulip):

We have a single place, and this place has multiple types, with different validity requirements.

gnzlbg (Feb 06 2019 at 12:50, on Zulip):

Depending on the value stored at this place, however, we have one type or the other.

gnzlbg (Feb 06 2019 at 12:51, on Zulip):

if we think of these types as Option::Some(&T) and Option::None

gnzlbg (Feb 06 2019 at 12:51, on Zulip):

OTOH, if we think of these types as Option<&T> and &T, then the place can be typed by both at the same time

gnzlbg (Feb 06 2019 at 12:52, on Zulip):

As in, the place is always either Option::Some or Option::None, and it sometimes is &T as well.

gnzlbg (Feb 06 2019 at 12:54, on Zulip):

Do we require validity to always hold (even if type is not used), or do we require validity to hold on use ?

gnzlbg (Feb 06 2019 at 12:55, on Zulip):

If we require validity to hold only on use / before the last use, then none of these examples are UB IMO. One writes through the reference to modify the discriminat, but the reference is not used afterwards.

RalfJ (Feb 06 2019 at 13:15, on Zulip):

If we require validity to hold only on use / before the last use, then none of these examples are UB IMO. One writes through the reference to modify the discriminat, but the reference is not used afterwards.

that's the point. is that really what we want? and if not, how can we make precise what we really want?

gnzlbg (Feb 06 2019 at 13:24, on Zulip):

Well, suppose that's not what we want. Then the validity of Option<T&> and T& both have to hold simultaneously for that single place AFAICT

rkruppe (Feb 06 2019 at 13:39, on Zulip):

how would you even make that precise without going into the hell that is typed memory? i don't want to end up with a rust where we need an equivalent of std::launder

gnzlbg (Feb 06 2019 at 13:44, on Zulip):

We probably just want to say that all values must be valid from creation till their last use.

gnzlbg (Feb 06 2019 at 13:46, on Zulip):

Alternatively, we could say that all values must be valid on use, but then we'd have to discuss whether creating a raw pointer to a value / place uses the value. If it does not use the value, we have pretty much the same validity as in C, where value must be valid when they participate in an lvalue expression.

gnzlbg (Feb 06 2019 at 13:47, on Zulip):

If creating a raw pointer to a value uses the value, there is nothing that you can actually do with an invalid value beyond dropping it (as long as it has no destructors), and we might as well require all values to be valid from creation until last use, and if that isn't enough, we can relax that later, in some useful way.

rkruppe (Feb 06 2019 at 14:02, on Zulip):

the only way i can parse any of this in a way other than "memory locations inherently have a type, and accesses that type-pun it must write bytes valid for the place's actual type" (i.e., typed memory) is as a sort of recursive , e.g. passing a &T around requires that it points at memory valid for T. that is an option (discussed in https://github.com/rust-rfcs/unsafe-code-guidelines/issues/77) but it doesn't make any of the examples in #84 UB

rkruppe (Feb 06 2019 at 14:04, on Zulip):

actually, come to think of it, not even typed memory would rule out any of this, you'd really need a "shadow discriminant" (as in https://github.com/rust-rfcs/unsafe-code-guidelines/issues/69#issuecomment-460195005), not just the knowledge that there's an Option<T> and a T in the same place

RalfJ (Feb 06 2019 at 14:32, on Zulip):

even the shadow discriminant does not fix the case where a bool is set to 2 and not used again

Last update: Nov 19 2019 at 17:40UTC