Reads of fields from invalid headers: additional options for return value

[grg]

The P4 language specification (v1.2.5, §8.25) states:

The result of reading a value in any of the situations below is that some unspecified value will be used for that field.

• reading a field from a header that is currently invalid.
• ...

The behavioral model currently returns that last written value when reading a field from an invalid header.

I propose adding two additional modes when reading from invalid headers:

1. Return 0: All reads of fields in invalid headers return 0. (Likely mirrors some hardware implementations.)
2. Return the last written value and print a warning.

I suggest that the choice of mode is a compile-time setting (e.g., via a cmake parameter).

[grg]

@fruffy / @jafingerhut Any objections to me adding these additional modes for invalid field reads?

[jafingerhut]

This sounds like a useful choice to have, and given that #2 in your list behaves the same way for packet processing behavior as the current code does, only generating additional warnings, that seems as backwards compatible as anyone would need.

[fruffy]

Yes, sounds reasonable. It makes sense to keep 2 the default since it puts emphasis that this is undefined behavior.

[grg]

I've opened a PR (#1377). I ended up making the warning/zero-return configurable via command-line parameters instead of compile-time defines. This seemed like the better approach for testing 🙂