temp_value being called during the read

[cjbissonnette]

I've got the following and am trying to use the temp_value to write out a sequence number during serialization:

#[deku(temp, temp_value="get_sequence()")]
sequence: u8,

It seems the temp_value is getting called during the de-serialization which I wouldn't expect. I would expect it to read the encoded value during the de-serialization, and use the temp_value when serializing.

Basically I have several spots in the protocol I want to read the value and use it as is during de-serialization, and provide some code during serialization. I know it could be achieved with update....but that has to be called manually with a mutable reference.

Is there any existing mechanism that would achieve this? I'm using 19.1.

[sharksforarms]

can you provide a minimal reproduction? this would help debug.

[cjbissonnette]

I'm sorry, I found my issue. I was calling To_bytes internally to calculate the CRC, but of course that is going to trigger the function, and the final to_bytes as the end will trigger it again. I'll have to think of a different way to accomplish this. Thanks for the reply, sorry for wasting your time.

I do have a feature request however. Would it be possible to add a flag such that the "update" function be called automatically if present before the serialization? I feel that would make that feature much more powerful.

[sharksforarms]

np!

Would it be possible to add a flag such that the "update" function be called automatically if present before the serialization?

yeah I wonder what could be done here. It's a trade-off, because as you previously noticed we need a &mut to update the value, which shouldn't be required for serialization. This is why it's explicit. A wrapper function around serialization could help here.

Another option is maybe some interior mutability type of setup, I haven't thought much about it as it feels anti-pattern'y

I agree likely most use cases would like to update on serialize, but this library doesn't want to make those assumptions and prefer flexibility

[cjbissonnette]

Sorry I was on vacation. Not to drag this out but I wanted to express my thought better. So instead of the update function modifying the structure (and needing mutability) I was thinking for a way to define a function which would be used as the output. This would work exactly like the "temp_value" but not require it to be "temp". This way a value could be read from a stream and deserialized, and on the output automatically replaced or updated via a function. Maybe it is just the protocol I'm working with, but I have several use cases where I would like to do that.

[sharksforarms]

sounds interesting, thanks for expanding! a code example of how you'd picture the usage would help further clarify

[cjbissonnette]

So basically I want the following to actually work (have a temp_value without it being temp). So if you are reading from this protocol you get the received sequence number and could run whatever validation code. When you serialize a message the value in the structure is not used, the output from the function is used in place. I would use this for the sequence, and I think for the CRC as well. I hope that makes it clear (I know I'm re-using the message, normally this would be a newly constructed message that the user wouldn't care about the sequence).

use deku::prelude::*;

fn get_sequence() -> u8 {
    use std::sync::atomic::{AtomicU8, Ordering};
    static SEQUENCE: AtomicU8 = AtomicU8::new(0);
    SEQUENCE.fetch_add(1, Ordering::Relaxed)
} 

#[deku_derive(DekuRead, DekuWrite)]
#[derive(Debug, PartialEq, Default, Clone)]
pub struct SimpleMessage {
    #[deku(temp_value="get_sequence()")]
    sequence: u8,
    pub payload:u32
}

#[test]
fn feature_test() {
    let input_bytes: Vec<u8> = vec![0x07,0x04, 0x00, 0x00, 0x00];

    let (_rest, deserialized_message) = SimpleMessage::from_bytes((&input_bytes, 0)).expect("Failed to parse");
    assert_eq!(deserialized_message.sequence, 7);
    assert_eq!(deserialized_message.payload, 4);
    
    let output_bytes = deserialized_message.to_bytes().expect("Failed to serialize");

    assert_eq!(Vec::from([0x00,0x04, 0x00, 0x00, 0x00]), output_bytes, "Roundtrip mismatch");
}

[sharksforarms]

would using a custom writer help with your use case?

use deku::prelude::*;

fn get_sequence() -> u8 {
    use std::sync::atomic::{AtomicU8, Ordering};
    static SEQUENCE: AtomicU8 = AtomicU8::new(0);
    SEQUENCE.fetch_add(1, Ordering::Relaxed)
}

fn write_sequence<W: std::io::Write + std::io::Seek>(
    writer: &mut Writer<W>,
) -> Result<(), DekuError> {
    let value = get_sequence();
    value.to_writer(writer, ())
}

#[deku_derive(DekuRead, DekuWrite)]
#[derive(Debug, PartialEq, Default, Clone)]
pub struct SimpleMessage {
    #[deku(writer = "write_sequence(deku::writer)")]
    sequence: u8,
    pub payload: u32,
}

fn main() {
    let input_bytes: Vec<u8> = vec![0x07, 0x04, 0x00, 0x00, 0x00];

    let (_rest, deserialized_message) =
        SimpleMessage::from_bytes((&input_bytes, 0)).expect("Failed to parse");
    assert_eq!(deserialized_message.sequence, 7);
    assert_eq!(deserialized_message.payload, 4);

    let output_bytes = deserialized_message
        .to_bytes()
        .expect("Failed to serialize");

    assert_eq!(
        Vec::from([
            0x00, // initial sequence
            0x04, 0x00, 0x00, 0x00
        ]),
        output_bytes,
        "Roundtrip mismatch"
    );

    let output_bytes = deserialized_message
        .to_bytes()
        .expect("Failed to serialize");

    assert_eq!(
        Vec::from([
            0x01, // sequence increase
            0x04, 0x00, 0x00, 0x00
        ]),
        output_bytes,
        "Roundtrip mismatch"
    );

    let output_bytes = deserialized_message
        .to_bytes()
        .expect("Failed to serialize");

    assert_eq!(
        Vec::from([
            0x02, // sequence increase
            0x04, 0x00, 0x00, 0x00
        ]),
        output_bytes,
        "Roundtrip mismatch"
    );
}

[cjbissonnette]

Yes this will absolutely work (and is what I ended up doing). I just thought because I needed this 3 times doing one example, other people may run into it as well. I guess as you point out, the customized reader/writer isn't much more code so maybe not worth it. I thought it might be super easy given the temp_value is like 99% of what would be needed. I really appreciate the project, and you spending time thinking about this. I won't bother you anymore with my musings. Thanks again.