Repository navigation
interpreter: compare an uninitialized value as 0 against a number - #149
Conversation
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.
|
This PR does two jobs at once, which is not bad, but I'm afraid we shouldn't merge the field-related changes at the moment; let's just keep the different type comparisons for unassigned values for now. I think first we should refactor the internal type implementation to use tagged pointers or other form of algebraic property management; the current disjoint representation is hard to manage and starts to suffer from combinatorial explosion. |
Alonely0
left a comment
There was a problem hiding this comment.
See my previous comment.
An uninitialized variable or array element is both "" and 0, so a comparison with a number is numeric: x == 0 and x > -1 are true for an unset x, as in gawk, mawk and nawk.
1d52995 to
eb7ebc6
Compare
|
Dropped the field part in eb7ebc6 and rebased on main. One side effect: fields past NF are |
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.
Alonely0
left a comment
There was a problem hiding this comment.
Nice! Merging this once CI passes.
An unset variable compared with a number uses string comparison, so
if (n == 0)is false for an unsetn:POSIX gives an uninitialized value both the string value "" and the numeric value 0, and compares numerically when the other side is a number.
==and the ordered comparisons now do that forUntyped/UnassignedagainstFloat,IntandBool. Against a string it is still a string comparison (x < "a"is 1,x == "0"is 0). While there: the(_, Untyped | Unassigned)arm ineqreadother.as_str()instead ofself.as_str(), so"" == xwas 0.Known gap: a field past NF is also
Unassigned, so$9 == 0now prints 1 (gawk and mawk print 0, main printed 0). Telling the two apart is left for the type rework.Tests:
uninitialized_value_compares_as_zero_with_a_numberfails without the change.cargo test --workspacepasses (test_awk 100), clippy andcargo fmt --checkare clean.