Add madvice and partial syserr to errno

[felixaszx]

This adds implementation of MADV_WILLNEED and MADV_DONTNEED (#11). I have not yet found any similar APIs for the rest of the standard posix MADV_*s. mremap (#19) is not a POSIX function, therefore I see no reason to have them in the future.

Also, win32 syserror to errno translation is also partially implemented. I remove deferr because it was never used.

Some changes in CMake has been made so there will not be anymore deprecated warnings.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the mman-win32 library by introducing support for the madvise system call, allowing applications to provide memory usage hints to the operating system. It also significantly improves error handling by mapping a wider range of Windows system errors to their corresponding POSIX errno values, making the library more robust and compatible. Additionally, build system improvements were made to ensure a cleaner compilation experience.

Highlights

• madvise Implementation: Implemented the madvise function, specifically supporting MADV_WILLNEED on Windows using PrefetchVirtualMemory. Other MADV_* flags are currently handled as no-ops or return EINVAL.
• Windows Error to POSIX errno Translation: Expanded the __map_mman_error function to provide a more comprehensive mapping of Windows system errors (DWORD) to standard POSIX errno values, including unwrapping FACILITY_WIN32 HRESULT errors.
• CMake Build System Update: Updated the CMakeLists.txt file to require CMake version 3.10, which helps in resolving deprecated warnings during the build process.
• Test Coverage for madvise: Added new test cases in test.c to verify the functionality of madvise for both anonymous and file-backed memory mappings.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces an implementation for madvise with MADV_WILLNEED and adds a mapping from Windows system errors to errno values. The changes are a good step forward, but I've found a few issues that should be addressed. There are a couple of high-severity issues in mman.c: one related to incorrect error handling for unmapped errors, and another concerning a fragile array size calculation that could lead to bugs. I've also noted some medium-severity issues, including the use of a magic number, inconsistent code formatting in a header file, and logic errors in the new tests that could cause them to pass even when the functionality being tested has failed. Please see my detailed comments for suggestions on how to resolve these points.