Re: IPv6 address parsing
Michael Powell <[email protected]>
| Newsgroups | gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <CAMEoF_EnEpDOqKrviwKs-Qgka6g4-nRcxO19nWVQ-Fbi504VrA@mail.gmail.com> |
Again, I am moving beyond IPv4 into IPv6. Do I need to re-post that
grammar attempt? Maybe I do at this point.
_dot = ".";
_col = char_(':');
_col_x2 = _col >> _col;
// _dec_octet = uint_parser<std::uint8_t, 10, 1, 3>();
qi::rule<Iterator> _dec_octet = ... ; // Approach TBD; probably
running with the IPv4 proposal discussed in earlier thread(s).
qi::rule<Iterator> _ipv4_addr = _dec_octet >> repeat(3)[_dot >> _dec_octet];
// or, qi::rule<Iterator> _ipv4_addr = raw[_dec_octet >> _dot >>
_dec_octet >> _dot >> _dec_octet >> _dot >> _dec_octet];
qi::rule<Iterator> _h16 = raw[repeat(1, 4)[hex]];
// Or (?): _h16 = hex >> -(hex >> -(hex >> -hex));
qi::rule<Iterator> _h16_col = _h16 >> _col;
qi::rule<Iterator> _ls32 = _h16_col >> _h16 | _ipv4_addr;
qi::rule<Iterator, std::string()> _ipv6_addr
= repeat(6)[_h16_col] >> _ls32
| _col_x2 >> repeat(5)[_h16_col] >> _ls32
| -(_h16) >> _col_x2 >> repeat(4)[_h16_col] >> _ls32
| -(_h16_col >> _h16) >> _col_x2 >> repeat(3)[_h16_col] >> _ls32
| -(repeat(1, 2)[_h16_col] >> _h16) >> _col_x2 >>
repeat(2)[_h16_col] >> _ls32
| -(repeat(1, 3)[_h16_col] >> _h16) >> _col_x2 >> _h16_col >> _ls32
| -(repeat(1, 4)[_h16_col] >> _h16) >> _col_x2 >> _ls32
| -(repeat(1, 5)[_h16_col] >> _h16) >> _col_x2 >> _h16
| -(repeat(1, 6)[_h16_col] >> _h16) >> _col_x2
;
qi::rule<Iterator> _start = _ipv6_addr >> eoi;
Q: Notwithstanding concern over raw IPv4, does the overall Qi-based
IPv6 grammar look reasonable? If not, why not?
I'd like to land in a Fusion data structure something like (string >>
uint16_t >> eoi), but if I can land here, that's acceptable, too:
(string >> -(uint8_t >> uint8_t >>
uint8_t >> uint8_t) >> uint16_t >> eoi).
From what I can determine, then, raw[...] is the difference between
parsed types like uint8_t and string?
ref: http://www.ietf.org/rfc/rfc5954.txt, section 4.1 Resolution for
Extra Colon in IPv4-Mapped IPv6 Address
Constructive feedback appreciated.
Untested ATM, to be fair.
On Thu, Dec 7, 2017 at 1:09 PM, Seth <[email protected]> wrote:
> On 07-12-17 18:21, Michael Powell wrote:
>> Well, you remembered incorrectly.
>
> I was asking.
>
>> If there's a doable intermediate step of parsed individual octets, so
>> be it; no problem.
>
> Please per-use all the parts of my answer.
>
> On 07-12-17 17:13, Seth wrote:
>> Maybe you'll be more convinced when it's demonstrated (I think I did
>> this before):
>>
>> https://wandbox.org/permlink/M12U5PEYcB8vnxIs
>>
>> It's really just ~3 lines of code changed:
>>
>> using ipv4_address = std::string; // much less useful representation
>> // ....
>> addr_ = raw[ octet_ >> '.' >> octet_ >> '.' >> octet_ >> '.' >>
>> octet_ ];
>>
>> Note now that test fails:
>
> It's all there.
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot