On Jan 11 18:43, Ken Brown wrote:
> On 1/8/2025 10:24 AM, Corinna Vinschen wrote:
> > On Jan 7 21:27, Ken Brown wrote:
> > > On 1/7/2025 3:18 PM, Corinna Vinschen wrote:
> > > > - mmap_record::prot flag, should be an array of protection bits per page
> > > > (POSIX page i e., 64K, not Windows page).
> > >
> > > Question: Since it only takes 3 bits to store all possible protections, do
> > > you think it's worth the trouble to pack the protections, so that each
> > > byte
> > > stores the protection bits for 2 pages? Or should I just use an array of
> > > unsigned char, with 1 byte for each page? Or did you have something else
> > > in
> > > mind?
> >
> > I hadn't thought deeply about this. I had a vague notion of a ULONG
> > array to match windows protection bits, but, as you note above, we
> > really only need 3 bits.
> >
> > I don't think we have to define this as a bit field array, given this
> > isn't readily available in C and you would have to add bitfield
> > arithmetic by yourself. So, yeah, a char or maybe better uint8_t
> > might be the best matching type here.
> 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];
Corinna
