GetFinalPathNameByHandleW should be audited #12406
Labels
O-windows
Operating system: Windows
Comments
|
It seems relatively likely that there would be other functions like this too. |
|
Sure, I was looking at this in conjunction with |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jul 25, 2022
…-without-block, r=Veykril fix: add an option to show inlay hint for return type of closures wit… fix rust-lang#12321
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Mar 7, 2024
…-of-core, r=Alexendoo Dedup std_instead_of_core by using first segment span for uniqueness Relates to rust-lang#12379. Instead of checking that the paths have an identical span, it checks that the relevant `std` part of the path segment's span is identical. Added a multiline test, because my first implementation was worse and failed that, then I realized that you could grab the span off the first_segment `Ident`. I did find another bug that isn't addressed by this, and that exists on master as well. The path: ```Rust use std::{io::Write, fmt::Display}; ``` Will get fixed into: ```Rust use core::{io::Write, fmt::Display}; ``` Which doesn't compile since `io::Write` isn't in `core`, if any of those paths are present in `core` it'll do the replace and cause a miscompilation. Do you think I should file a separate bug for that? Since `rustfmt` default splits those up it isn't that big of a deal. Rustfmt: ```Rust // Pre use std::{io::Write, fmt::Display}; // Post use std::fmt::Display; use std::io::Write; ``` --- changelog: [`std_instead_of_core`]: Fix duplicated output on multiple imports
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The call to
GetFinalPathNameByHandleW()insrc/libnative/io/file.rsneeds to be audited. I am not a Windows developer, but my interpretation of the documentation indicates that the buffer length provided to that function should be 1 less than the actual buffer size. The reasoning is that the documentation states:yet the function itself will NULL-terminate the output it writes. To me this says that it will write one more TCHAR to the buffer than is indicated by
cchFilePath.This should be verified by someone who is actually familiar with Windows APIs.
The text was updated successfully, but these errors were encountered: