Is there a built in way to read/write a vector of bits/bool?

[yanshay]

Is there a built in way to read/write a vector of bits/bool?

[wcampbell0x2a]

Away from my computer, but this should work:

use deku::prelude::*;

#[derive(Debug, PartialEq, DekuRead, DekuWrite)]
struct Bit(#[deku(bits = "1")] u8);

#[derive(Debug, PartialEq, DekuRead, DekuWrite)]
struct Container {
    qty: u8,
    #[deku(count = "qty")]
    bits_data: Vec<Bit>,
}

I would even prefer to read/write into BitVec for easier access and optimal memory footprint.

Interesting idea, I'd support a MR for this.

[yanshay]

Thanks, that works. I also added padding as in the code below to align on bytes boundary. Its also required for try_form not to fail on too much data. See below.

#[derive(Debug, PartialEq, DekuRead, DekuWrite)]
struct BitContainer {
    qty: u8,
    #[deku(count = "qty", pad_bits_after="(qty+7)/8*8-qty")]
    bits_data: Vec<Bit>,
    field_after: u8
}

What's still missing is automatic filling of qty on write, so I won't need to fill it in the code.

1. I can't do it using writer, because the pad_bits_after would not work. On read I need padding to refer to the read qty but on write I need it to refer to the length of bits_data. (Interestingly, from my tests, on write deku ignores the 'qty' and decides how many bits to save based on the Vec<Bit> size, I think this is worth explaining in the documentation)
2. I can solve this using update on the qty field. But that's error prone since it requires client code to remember to update prior to save. I think there would be value in having an attribute update_on_write that executes right before write and has access to self that can calculate automatically fields that can be deduced from other fields
3. I can do it using writer/reader for only bits_data and expose only bits_data with qty taken care of behind the scene.
4. Could I define a new type type MyVecBit = Vec<Bit> and implement relevant traits to do the same as 4, only seamlessly from the person defining the structure? Any examples for that? Because this pattern will be used in multiple structures and I don't want to have verbose definitions all over

[wcampbell0x2a]

I think there would be value in having an attribute update_on_write that executes right before write and has access to self that can calculate automatically fields that can be deduced from other fields

Agreed, this would need to be a breaking change, as DekuWrite doesn't mutate self.