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

Modify max_stack_height of type section #134

Open
Tracked by #165
chfast opened this issue Jun 23, 2024 · 1 comment
Open
Tracked by #165

Modify max_stack_height of type section #134

chfast opened this issue Jun 23, 2024 · 1 comment

Comments

@chfast
Copy link
Member

chfast commented Jun 23, 2024

CALLF/JUMPF requires number of target inputs for stack overflow check, because max_stack_height definition includes function inputs, and we need to subtract them not to double count.

Originally posted by @gumb0 in #39 (comment)

The third value of the type section entry (after number of inputs, number of outputs) should be "max stack height above the inputs". This eliminates "double counting" as you can notice in the current spec that the max_stack_height >= num_inputs. This also simplifies the runtime stack overflow check at CALLF/JUMPF: it only needs to access the new value.

@pdobacz
Copy link
Member

pdobacz commented Jun 24, 2024

When last discussed (discord), this fell into the "too late" department. Andrei suggested a name max_stack_increase back then, I think renaming would indeed be necessary, otherwise max_stack_height == 0 and inputs > 0 is weird.

Barring the lateness argument, and assuming we rename the field, this sounds like a positive change.

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