Clarification question on setInvalid

[fruffy]

I am trying to understand the exact implications of setValid and setInvalid

Let's assume I have the following sequence of operations:

control ingress(inout Parsed_packet hdr, inout Metadata meta, inout standard_metadata_t stdmeta) {
    apply {
        hdr.h.a = 8w1;
        hdr.h.setInvalid();
        hdr.h.b = 8w1;
        hdr.h.setValid();
        hdr.h.b = 8w2;
    }
}

which after a FrontEnd pass turns into:

control ingress(inout Parsed_packet hdr, inout Metadata meta, inout standard_metadata_t stdmeta) {
    apply {
        ;
        hdr.h.setInvalid();
        ;
        hdr.h.setValid();
        hdr.h.b = 8w2;
    }
}

From the spec I was unable to read out the exact behavior of setInvalid, however
from this snippet I can infer that assignments to an invalid header are void.

What I am little confused about is the erasure of the first assignment.
At this point the header was still valid, does setInvalid free or zero the data stored at the header reference? Or is the behavior undefined? If it is undefined, should the compiler make the assumption that all previous assignments are void? Couldn't this behaviour differ based on the backend?

[jnfoster]

After the execution of hdr.h.setInvalid() reading a field in hdr.h will return an undefined value. Therefore it's safe for the compiler to eliminate the assignment to hdr.h.a.

Regarding the question "Couldn't this behaviour differ based on the backend?" Yes, the behavior could differ. But since the language specification says that reading fields in h returns an undefined value, the front-end is free to apply program transformations that do not preserve the values in those fields, even if some specific backends might implement hdr.h.setInvalid(); hdr.h.setValid() as a no-op.

[fruffy]

Thank you for the quick reply and clarification. That answers my question.