[PATCH] Cygwin: mmap: allow remapping part of an existing anonymous, mapping
Ken Brown
kbrown@cornell.edu
Mon Jan 13 22:36:17 GMT 2025
On 1/13/2025 6:00 AM, Corinna Vinschen wrote:
> On Jan 11 18:43, Ken Brown wrote:
>> Another question: Adding this array to mmap_record, we have two flexible
>> arrays in the class: one for page_map and one for the protection array. My
>> understanding is that a class or struct can have only one flexible array
>> member, and it has to be at the end. What's the best way to deal with that?
>> The only thing I can think of is to use a pointer instead of an array for
>> the protections, and then allocate memory for it separately when an
>> mmap_record is created. Or is there a better way?
>
> Excellent question. Right now the page map is a bitwise array, one bit
> per page. From the top of my head I think the best way to deal with
> that is to just change the existing page_map to a uint8_t per page and
> store the mapping state in the upper bits and the protection in the
> lower bits.
>
> Alternatively, define a bitfield, kind of like this:
>
> struct {
> uint8_t protection:3;
> uint8_t mapped:1;
> } page_map[0];
Thanks. Both of these ideas are better than what I had in mind. By the
way, I forgot about __PROT_ATTACH when I said we need 3 bits for the
protection, so it's actually 4 bits. If I decide to use your first
suggestion, those 4 bits would have to be consecutive. I assume it's OK
to redefine __PROT_ATTACH to be 8 rather than 0x8000000? Or is there
some reason that would be bad?
Ken
More information about the Cygwin-patches
mailing list