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
{{ message }}
This repository has been archived by the owner on Aug 20, 2021. It is now read-only.
I was just looking through the code("looking for inspiration") and observed a bug that is the equivalent of dangling pointers but with Rust Options(of course, no memory corruption).
When calling into_path, path will be replaced with None - then -> if somebody calls the path function, the application will panic(because it unwraps for the user - which would be the equivalent of dereferencing a dangling pointer).
I think it's better to break the API(v0.4) and make this function return an Option<&path::Path>, or maybe some other option(solution).
The text was updated successfully, but these errors were encountered:
My mistake.
Because into_path takes mut self and not &mut self, TempDir is released and there is no risk of using this resource later - very nice.
I will use the same technique - seems like I did get "inspired" in the end 😄
lilianmoraru
changed the title
Equivalent of dangling pointer dereferencing when calling path after into_path
(Not)Equivalent of dangling pointer dereferencing when calling path after into_pathMar 5, 2017
I was just looking through the code("looking for inspiration") and observed a bug that is the equivalent of dangling pointers but with Rust
Option
s(of course, no memory corruption).When calling
into_path
,path
will be replaced withNone
- then -> if somebody calls thepath
function, the application will panic(because it unwraps for the user - which would be the equivalent of dereferencing a dangling pointer).I think it's better to break the API(
v0.4
) and make this function return anOption<&path::Path>
, or maybe some other option(solution).The text was updated successfully, but these errors were encountered: