Re: [Qi] Phrase parsed but iterator did not reach end

On Wed, Nov 29, 2017 at 6:40 PM, Seth <[email protected]> wrote:
> On 29-11-17 22:42, Michael Powell wrote:
>> https://wandbox.org/permlink/04tVHUZZN8j3PfAB
>>
>> But I can't fathom what. Spirit Qi -wise, I think it's fine, but I
>> could be missing something, and obviously the matched attributes are
>> telling their own story.
>
> First, simplify
>
> https://wandbox.org/permlink/Phb2Xn3aqdbO6rhG
>
>  - Next, change the AST to be useful (storing the input string makes
> "127.00.00.1:443" different from "127.0.0.1:443".
>
>  - In fact https://en.wikipedia.org/wiki/IPv4#Address_representations
> tells me you can have "0x7f.0.0.00001:443".
>
>  - I tested this to be consistent with how `ping` parses its command
> line arguments (e.g. ping '1.000014.0x7b.003' pinged 1.12.123.3).
>
>  - Also, whitespace is not admissable after all, so let's drop the skipper.
>
> The meat of it is in these rules:
>
>             octet_ = "0x" >> uint_parser<uint8_t, 16, 2, 2>() // 0x00 style
>                    | "0" >> uint_parser<uint8_t, 8, 1, 5>()   // 0020
> (for decimal 32) style
>                    | uint_parser<uint8_t, 10, 1, 3>();        // dot-decimal
>
>             addr_  = octet_ >> '.' >> octet_ >> '.' >> octet_ >> '.' >>
> octet_;
>             port_  = uint_parser<uint16_t, 10, 1, 5>();

Actually, I think whitespace is allowed, but not in the octet itself,
hence the lexeme. But I think this is valid, 127  . 0.  0. 1, for
example. I could be wrong about that, and it wouldn't be a bad idea to
be more stringent there.

Do you have an RFC for any of those representations?

Just besides, however, I'm just looking at the base 10 uint8_t
representation at the moment. I know for sure about the base 10
(0-255).

But did you test the uint_parser for this, actually? When I tried
that, the parser was accepting ranges beyond 0-255, which is
incorrect. i.e.

... uint_parser<uint8_t, 10, 1, 3>() ...

One incorrect edge case is 256, for example. Should be rejected.

> I've added a few to test the new capabilities and some rejections too:
>
> https://wandbox.org/permlink/Wsr1E92HWO8WrxMX

Thanks, I'll have a look.

> Bonus tip: consider adding `>> qi::eoi` at the end of the parse
> expression so you don't need to check whether all of the input has been
> consumed (it must).
>
> AMDG
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot