On Mon, Nov 27, 2017 at 4:39 PM, Michael Powell
Hello,
I've got the following parsers which are failing to find the correct attributes.
I tried to parse in terms of uint_parser
() at first, but this was not working properly. So I tried the following:
_octet_rule = lexeme[ char_('0') | (char_('1') >> -(digit >> -digit)) | (char_('2') >> -((char_('0', '4') >> -(digit)) | (char_('5') >> -(char_('0', '5'))) | char_('6', '9') ) ) | (char_('3', '9') >> -digit) ];
Which is presently failing to find all three digits in the "20\d"-"24\d" use case.
Octet itself parses correctly when I use this rule:
_octet_rule >> !(char_);
My octet test cases verify the entire range of 0-255 successfully, as well as the following invalid cases:
VerifyOctet(-1, invalid_);
VerifyOctet(1990, invalid_); VerifyOctet(2550, invalid_); VerifyOctet("255.", invalid_); VerifyOctet(256, invalid_); VerifyOctet(999, invalid_);
VerifyOctet("abc", invalid_); VerifyOctet(123.456, invalid_);
Converted to corresponding string, i.e. "1990" or "123.456".
But when I combine that into the IP address rule, the test results occur:
_octet_rule >> repeat(3)[char_('.') >> _octet_rule];
And the test results:
CHECK_THAT( y, Equals(x) ) with expansion: "145.23.183.47" equals: "145.231.183.47" with message: Verifying address >>> 145.231.183.47 <<<
FAILED: CHECK_THAT( y, Equals(x) ) with expansion: "189.21.29.11" equals: "189.211.29.11" with message: Verifying address >>> 189.211.29.11 <<<
FAILED: CHECK_THAT( y, Equals(x) ) with expansion: "90.60.32.24" equals: "90.60.32.246" with message: Verifying address >>> 90.60.32.246 <<<
FAILED: CHECK_THAT( y, Equals(x) ) with expansion: "22.59.144.140" equals: "223.59.144.140" with message: Verifying address >>> 223.59.144.140 <<<
Perhaps I should have more test cases represented as well, because when the 2's is the single digit, I get a space interpreted. Which is starting to look like a "skipper" issue to me? FAILED: CHECK_THAT( y, Equals(x) ) with expansion: "22.23.2 .152" equals: "221.236.2.152" ^^^^ with message: Verifying address >>> 221.236.2.152 <<<
IP address test data is randomly generated, or combinatorially if I wanted to wait for all 4.3B or so test cases. However, I figure that as long as the Octet rule is working, it is reasonable to expect the Address rule may also work.
Not sure why those last digits are being dropped, however. Or how the 1's can succeed where the 2's are failing.
Any suggestions, Spirit folks?
Thanks!
Cheers,
Michael Powell