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
Error parsing "cond && var=value" #166
Comments
I haven't gone through all the cases in my repo, but there are three differences (from all gawk, onetrueawk and mawk) I remember having noticed:
I'm not sure what would be "the correct" parse for 2. and 3. in terms of the posix spec, but all the other major implementations seem to behave the same way. Also the 2. and 3. might be somewhat related. At least both parse similarly (using the gawk pretty-printing option):
Going on a tangent... I just noticed while writing this, that the handling of the non-associative operators is all over the place when there is no assignment expressions involved: gawk accepts chaining of match-ops (left-associative), but not comparisons:
onetrueawk rejects both with similar error message:
and mawk accepts both (left-associative):
In conclusion, I'd hope that any important awk code would be written in more unambiguous style 😅 |
Thanks @juntuu! After I submitted this issue I did go through all the solutions in your repo that were failing in GoAWK, and that's the list I came up with too. Yep, I figured I'd address the As far as the POSIX spec goes, it says that |
Expressions like "1 && x=1" aren't really valid (IMO), because assignments are lower-precedence than binary operators, but onetrueawk, Gawk, and mawk all support this for logical, match and comparison operators. The other awks support this by using a yacc grammar which supports backtracking, and as Vitus13 said on reddit: "If there are two syntactically valid parsings and one is a semantic error, the error handling may resolve the ambiguity towards the valid parsing. In this case, you can only assign to L values, so trying to assign to (1&&x) doesn't make any sense." In GoAWK, this requires a form of backtracking (I call it "partial backtracking" because it's not actually backing up the lexer). It works by parsing as (1&&x)=1 according to the operator precedence, then determining that you're trying to assign something that isn't an lvalue, then confirming that 1&&x is a binary expression, that the "x" part is an lvalue, and that the operator (&& in this case) is one that the other awks handle similarly for this case. Also make the error message a bit clearer when you don't have an lvalue on the left hand side of an assignment, like "rand() = 1". Fixes #166
Expressions like "1 && x=1" aren't really valid (IMO), because assignments are lower-precedence than binary operators, but onetrueawk, Gawk, and mawk all support this for logical, match and comparison operators. The other awks support this by using a yacc grammar which supports backtracking, and as Vitus13 said on reddit: "If there are two syntactically valid parsings and one is a semantic error, the error handling may resolve the ambiguity towards the valid parsing. In this case, you can only assign to L values, so trying to assign to (1&&x) doesn't make any sense." In GoAWK, this requires a form of backtracking (I call it "partial backtracking" because it's not actually backing up the lexer). It works by parsing as (1&&x)=1 according to the operator precedence, then determining that you're trying to assign something that isn't an lvalue, then confirming that 1&&x is a binary expression, that the "x" part is an lvalue, and that the operator (&& in this case) is one that the other awks handle similarly for this case. Also make the error message a bit clearer when you don't have an lvalue on the left hand side of an assignment, like "rand() = 1". Fixes #166
This is valid in Gawk, onetrueawk, and mawk, but not in GoAWK (incidentally, frawk has the same issue).
Discovered from the results at https://github.com/juntuu/advent_of_code_2022 (see results)
There are probably more issues this repo has found in GoAWK -- would be worth going through all the failures to find other unique issues.
The text was updated successfully, but these errors were encountered: