-
Notifications
You must be signed in to change notification settings - Fork 528
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
Fix Tokenizer::int64() parsing of "0" when guessing base #1842
Fix Tokenizer::int64() parsing of "0" when guessing base #1842
Conversation
Known bug victims in current code were client_connection_mark and (deprecated) clientside_mark ACLs if they were configured to match a zero mark using "0/..." syntax: ERROR: configuration failure: NfMarkConfig: invalid value '0/10'... exception location: NfMarkConfig.cc(23) getNfmark Probably broken since 2014 commit 01f2137.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some missing tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With @eduard-bagdasaryan's help, I added four directives to the two ACLs declared as known to be affected in this PR description: tcp_outgoing_mark, mark_client_packet, clientside_mark, and mark_client_connection. Their parser is parse_acl_nfmark() which calls Ip::NfMarkConfig::Parse() which ends up calling getNfmark() that calls int64() with zero base. |
CPPUNIT_ASSERT_EQUAL(benchmark,rv); | ||
CPPUNIT_ASSERT_EQUAL(SBuf(""), t.buf()); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we need also to test overflow with a zero-leading huge value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, better overflow tests would be useful, but they are outside the current PR scope IMO. Writing a good black-box leading-zero overflow test is not trivial. Adding a white-box leading-zero overflow test is not needed -- int64() loop is currently not counting the number of digits in any way and, hence, does not care if there are leading zeros AFAICT. Let's not add those tests (in this PR).
P.S. I added (useful) +0
and -0
tests because adding them was trivial. They are arguably in this PR scope.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@yadij, please unblock this head-of-queue PR. It has no known blocking problems and has been waiting for your review for more than a week. |
FYI, resync with master to kick a retry of the failed tests on c409c33 |
Known bug victims in current code were tcp_outgoing_mark, mark_client_packet, clientside_mark, and mark_client_connection directives as well as client_connection_mark and (deprecated) clientside_mark ACLs if they were configured to match a zero mark using "0" or "0/..." syntax: ERROR: configuration failure: NfMarkConfig: invalid value '0/10'... exception location: NfMarkConfig.cc(23) getNfmark Probably broken since 2014 commit 01f2137.
…#1842) Known bug victims in current code were tcp_outgoing_mark, mark_client_packet, clientside_mark, and mark_client_connection directives as well as client_connection_mark and (deprecated) clientside_mark ACLs if they were configured to match a zero mark using "0" or "0/..." syntax: ERROR: configuration failure: NfMarkConfig: invalid value '0/10'... exception location: NfMarkConfig.cc(23) getNfmark Probably broken since 2014 commit 01f2137.
Known bug victims in current code were tcp_outgoing_mark,
mark_client_packet, clientside_mark, and mark_client_connection
directives as well as client_connection_mark and (deprecated)
clientside_mark ACLs if they were configured to match a zero mark using
"0" or "0/..." syntax:
Probably broken since 2014 commit 01f2137.