-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What is the UB behaviour of accessing *mut through &T #1227
Comments
No, if the |
@bjorn3 I'm the bespoken user. The OP is talking about a case like: struct Foo(*mut i32);
unsafe fn bar(v: &Foo) {
*v.0 = 123;
} Not something like: struct Foo(i32);
unsafe fn bar(v: &Foo) {
*(&v.0 as *const i32 as *mut i32) = 123;
} Are you referring to that too, or have you talked about the cast case? |
I see. The first snippet is fine. |
Thank you for your help. Maybe what I am confused about is that rust does not consider the I want treat my
I am suprised such a wrapper does not already exist in the stdlib, so I suspect that it does and I have missed it. |
This wrapper is called |
I personally found this description of UB confusing, since the use of "reached" suggests that UB only happens for read bytes, and the definition of immutability is not given, allowing for multiple interpretations: does the "data" have to be immutable from the first read? From the creation of the reference? Between reads from the immutable accessor, but not otherwise? etc. This clarifies the actual UB conditions, based on this Zulip interaction: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/What.20exactly.20are.20.22immutable.22.20and.20.22reached.22.20in.20shared.20ref.20UB.3F and this reference discussion: rust-lang#1227 in two ways: * The definition of "data" is clarified to be stated in terms of bytes, in a way that should avoid ambiguity about which bytes are considered. Based on the GH issue, this clarification should also allow for use of a `*mut` pointer through a shared reference, which is not in itself UB. Based on the Zulip issue, the definition includes padding bytes, which may be surprising. * The definition of immutability & mutation for a set of bytes is clarified to mean forbidding *all* non-0-byte writes.
I personally found this description of UB confusing, since the use of "reached" suggests that UB only happens for read bytes, and the definition of immutability is not given, allowing for multiple interpretations: does the "data" have to be immutable from the first read? From the creation of the reference? Between reads from the immutable accessor, but not otherwise? etc. This clarifies the actual UB conditions, based on this Zulip interaction: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/What.20exactly.20are.20.22immutable.22.20and.20.22reached.22.20in.20shared.20ref.20UB.3F and this reference discussion: rust-lang#1227 in two ways: * The definition of "data" is clarified to be stated in terms of bytes, in a way that should avoid ambiguity about which bytes are considered. Based on the GH issue, this clarification should also allow for use of a `*mut` pointer through a shared reference, which is not in itself UB. Based on the Zulip issue, the definition includes padding bytes, which may be surprising. * The definition of immutability & mutation for a set of bytes is clarified to mean forbidding *all* non-0-byte writes.
I personally found this description of UB confusing, since the use of "reached" suggests that UB only happens for read bytes, and the definition of immutability is not given, allowing for multiple interpretations: does the "data" have to be immutable from the first read? From the creation of the reference? Between reads from the immutable accessor, but not otherwise? etc. This clarifies the actual UB conditions, based on this Zulip interaction: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/What.20exactly.20are.20.22immutable.22.20and.20.22reached.22.20in.20shared.20ref.20UB.3F and this reference discussion: rust-lang/reference#1227 in two ways: * The definition of "data" is clarified to be stated in terms of bytes, in a way that should avoid ambiguity about which bytes are considered. Based on the GH issue, this clarification should also allow for use of a `*mut` pointer through a shared reference, which is not in itself UB. Based on the Zulip issue, the definition includes padding bytes, which may be surprising. * The definition of immutability & mutation for a set of bytes is clarified to mean forbidding *all* non-0-byte writes.
reference/src/behavior-considered-undefined.md
Line 31 in 683bfe5
I was wondering how to use *mut pointers in more safe way, I asked this question: https://stackoverflow.com/questions/72541045
A user responded that I read this paragraph wrong, and that modifying data through both
UnsafeCell<U>
AND*mut U
would not be UB. Does the above paragraph need to mention raw pointers?The text was updated successfully, but these errors were encountered: