-
Notifications
You must be signed in to change notification settings - Fork 13.9k
dangling pointer from temp cleanup #148490
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
base: master
Are you sure you want to change the base?
Conversation
| .note = pointers do not have a lifetime; when calling `{$callee}` the `{$ty}` will be deallocated at the end of the statement because nothing is referencing it as far as the type system is concerned | ||
| .help_bind = you must make sure that the variable you bind the `{$ty}` to lives at least as long as the pointer returned by the call to `{$callee}` | ||
| .help_returned = in particular, if this pointer is returned from the current function, binding the `{$ty}` inside the function will not suffice | ||
| lint_dangling_pointers_from_temporaries = expression creates a dangling pointer to dropped temporary `{$ty}` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that's the a good description of the issue, I feel like it's a bit misleading, the temporary is not yet dropped (otherwise this would insta UB), it's dropped only after creating the pointer, and it's the dropping of the temporary which makes the pointer dangling.
The previously wording was clearer IMO on this point. Not sure how to best improve that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I thought that detail did not matter. Do you have a reference for your claim that that would be insta UB?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a reference for your claim that that would be insta UB?
For String::new().DROPPED.as_ptr() it's apparently a grey area rust-lang/unsafe-code-guidelines#188 where use-after-dropped and use-after-free are different regarding opsem. I was told that it should probably be UB and is heavily discouraged.
But for allocation like "".to_string().DROPPED.as_ptr() Miri flags it as UB1 on the as_ptr() call, so 🤷
Footnotes
| .ret_ty = return type is `{$ret_ty}` | ||
| .local_var = local variable `{$local_var_name}` is dropped at the end of the {$fn_kind} | ||
| .created_at = dangling pointer created here | ||
| .help_visit = for more information, see <https://doc.rust-lang.org/reference/destructors.html> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not used right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I forgot to wire that up. Will fix.
| .help_bind = you must make sure that the variable you bind the `{$ty}` to lives at least as long as the pointer returned by the call to `{$callee}` | ||
| .help_returned = in particular, if this pointer is returned from the current function, binding the `{$ty}` inside the function will not suffice | ||
| lint_dangling_pointers_from_temporaries = expression creates a dangling pointer to dropped temporary `{$ty}` | ||
| .label_ptr = dangling pointer created here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also is misleading IMO, it's not yet dangling but it will be.
Continuation of #148348
r? @Urgau