[Boost-users] [Spirit.Qi] failing to parse IP address octets

Subject: [Boost-users] [Spirit.Qi] failing to parse IP address octets
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2017-11-27 21:39:57

Hello,

I've got the following parsers which are failing to find the correct attributes.

I tried to parse in terms of uint_parser<uint8_t, 10, 1, 3>() 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 <<<

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