Skip to content
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

Bug: MapViewOfFile returns an isize in 0.48 #2436

Closed
sunfishcode opened this issue Apr 10, 2023 · 6 comments
Closed

Bug: MapViewOfFile returns an isize in 0.48 #2436

sunfishcode opened this issue Apr 10, 2023 · 6 comments
Labels
bug Something isn't working

Comments

@sunfishcode
Copy link

Which crate is this about?

windows-sys

Crate version

0.48.0

Summary

It appears in 0.48 that MapViewOfFile changed from returning *mut c_void to returning MEMORYMAPPEDVIEW_HANDLE, which is an isize.

According to the MapViewOfFile documentation, the return type is LPVOID and the return value does represent an address. Representing it as a pointer would more convenient for typical use cases which use it as a pointer, and would be friendlier to strict provenance checks.

Toolchain version/configuration

No response

Reproducible example

No response

Crate manifest

No response

Expected behavior

No response

Actual behavior

No response

Additional comments

No response

@sunfishcode sunfishcode added the bug Something isn't working label Apr 10, 2023
@ChrisDenton
Copy link
Collaborator

See also microsoft/win32metadata#561 where this change was made

@sunfishcode
Copy link
Author

The reasoning about strict provenance in #1643 seems to be that it's ok that handles are represented as isize because they're never used as pointers by applications.

However now, it seems there exists a thing which is a handle, and that is also used as a pointer by applications.

@riverar
Copy link
Collaborator

riverar commented Apr 10, 2023

Looks like a metadata bug and should have never been marked as returning a handle. Will re-open that bug.

@kennykerr
Copy link
Collaborator

Yes, this is a bug in the win32 metadata.

@kennykerr
Copy link
Collaborator

Looks like this was tweaked in the Win32 metadata microsoft/win32metadata#561 so I'll close this - let me know if there's anything else you need.

@kennykerr
Copy link
Collaborator

FYI: microsoft/win32metadata#1533

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants