Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What can minSizeInBits (etc.) be applied to #1318

Open
vlstill opened this issue Oct 17, 2024 · 1 comment
Open

What can minSizeInBits (etc.) be applied to #1318

vlstill opened this issue Oct 17, 2024 · 1 comment

Comments

@vlstill
Copy link
Contributor

vlstill commented Oct 17, 2024

The specifications says

The method calls minSizeInBits, minSizeInBytes, maxSizeInBits, and maxSizeInBytes can be applied to some expressions.

But it is not very explicit what kinds of expressions these can be. From the description below the table, it it seems it is applicable to typedef- and type-introduced types. But what else?

  1. The P4C has a test where it applies these methods to values, probably yielding the size of the type that the value has. Is this intended to be permitted?
  2. The P4C accepts application of these methods to headers.
  3. In P4C, it is not possible apply them to bit<N>, i.e. both bit<4>.minSizeInBits() and (bit<4>).minSizeInBits() fails (with different errors).
  4. Also in P4C, it is not possible to apply them to generic type parameters bit<4> test<T>() { return T.minSizeInBits(); } does not work. And this does not work also for generic values.

Frankly, I find this syntax a bit clunky, but given its existence, I think this should be cleaned up. I find it weird, that it can be applied to some concrete types (like headers), while not to others (like bit<4>). Also, I wonder if it should be permitted to use it for generic types (although I don't see a use case right now). Obviously such value would not be local compile time know. It can be only know after the function is inlined and the types are know. But at the very least, we should make the constraints much more explicit in the specification.

@jafingerhut
Copy link
Collaborator

The primary reason for introducing these methods was for applying them to variables with a header type, so if the spec is not explicit that this should be supported, that sounds like a good change to make to the spec.

Any other values or types it can apply to are simply bonuses, in my opinion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants