-
Notifications
You must be signed in to change notification settings - Fork 38
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
&max-size
has effect on how much data is consumed
#1668
Labels
Bug
Something isn't working
Comments
bbannier
added a commit
that referenced
this issue
Feb 5, 2024
We would previously handle `&size` and `&max-size` almost identical with the only difference that `&max-size` sets up a slightly larger view to accomodate a sentinel. In particular, we also used identical code to set up the position where parsing should resume after such a field. This was incorrect as it is in general impossible to tell where parsing continues after a field with `&max-size` since it does not signify a fixed view like `&size`. In this patch we now compute the next position for a `&max-size` field by inspecting the limited view to detect how much data was extracted. Closes #1668.
bbannier
added a commit
that referenced
this issue
Feb 5, 2024
We would previously handle `&size` and `&max-size` almost identical with the only difference that `&max-size` sets up a slightly larger view to accomodate a sentinel. In particular, we also used identical code to set up the position where parsing should resume after such a field. This was incorrect as it is in general impossible to tell where parsing continues after a field with `&max-size` since it does not signify a fixed view like `&size`. In this patch we now compute the next position for a `&max-size` field by inspecting the limited view to detect how much data was extracted. Closes #1668.
bbannier
added a commit
that referenced
this issue
Feb 7, 2024
We would previously handle `&size` and `&max-size` almost identical with the only difference that `&max-size` sets up a slightly larger view to accomodate a sentinel. In particular, we also used identical code to set up the position where parsing should resume after such a field. This was incorrect as it is in general impossible to tell where parsing continues after a field with `&max-size` since it does not signify a fixed view like `&size`. In this patch we now compute the next position for a `&max-size` field by inspecting the limited view to detect how much data was extracted. Closes #1668.
This was referenced Feb 7, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I would expect
&max-size
to inject a post-condition into parsing, but not have an effect on how much data is consumed (unless there is an error). This is not the case, e.g., in below reproducer regardless of whether&max-size
was used or not,rest
should always beb"BC"
,Instead the following output is produced:
The error is in how
&max-size
sets the next position,spicy/spicy/toolchain/src/compiler/codegen/parser-builder.cc
Line 704 in 041a072
Contrary to what we currently do,
&max-size
is completely different from&size
wrt.ncur
which depends on what was actually parsed and cannot be known or set before.I came across this while working on #1652.
The text was updated successfully, but these errors were encountered: