The spec for header union operations seems incomplete about p4-spec HOT 7 CLOSED

However, the spec implies that this is not true.

from p4-spec.

@mbudiu-vmw wrote: "Second, there is no discussion about the semantics of assigning invalid fields."

It appears to me that the spec is quite explicit on this topic. Quoting from Section 8.19 "Operations on Header Unions" below:

We can understand an assignment to a union field

u.hi = e
as equivalent to

  u.hi.setValid();
  u.hi = e;
if e is valid and

  u.hi.setInvalid();
otherwise.

If I am interpreting that correctly, then your example code in the original comment above:

header_union HU { H1 h1; H2 h2; }
HU u;
H1 h;
h.setInvalid();
u.field =h;

The spec explicitly says that the u should end in a state where all of its members are invalid.

How can that section of the spec be interpreted otherwise?

from p4-spec.

The spec does not explain whether an existing valid field is invalidated when assigning a different field with an invalid value. Either interpretation would be possible.

from p4-spec.

Please read the entire section on operations on header unions and tell me if you still believe it is open to interpretation. I don't see how it is. For example, see this text:

More formally, if u is an expression whose type is a header union U with fields ranged over by hi, then the following operations can be used to manipulate u:

u.hi.setValid(): sets the valid bit for header hi to true and sets the valid bit for all other headers to false, which implies that it is unspecified what value reading any member header of u will return.

u.hi.setInvalid(): if the valid bit for any member header of u is true then sets it to false, which implies that it is unspecified what value reading any member header of u will return.

from p4-spec.

If you mean that this phrase is ambiguous "if the valid bit for any member header of u is true then sets it to false", I believe the intent when it was written was more explicitly the following.

"assign false to the valid bit for every member header of u"

I would be open to changing that sentence to be more explicit if you think it is open to interpretation.

from p4-spec.

Fixed by #1220

from p4-spec.

Closing this issue, as it appears to have been resolved by the commit mentioned by Mihai above.

from p4-spec.