Re: Domain name parser not working

Michael Powell <[email protected]>
Newsgroups gmane.comp.parsers.spirit.general
Message-ID <CAMEoF_EeQYi6Cr1eDUDL1YH+pX-sBL4D011Bo7XyVV0p7-DjYg@mail.gmail.com>
On Mon, Jan 1, 2018 at 7:32 PM, Michael Powell <[email protected]> wrote:
> On Mon, Jan 1, 2018 at 7:11 PM, Michael Powell <[email protected]> wrote:
>> On Mon, Jan 1, 2018 at 6:49 PM, Michael Powell <[email protected]> wrote:
>>> Hello,
>>>
>>> // Where Let is char_(/*upper/lower-case chars*/), Dig is
>>> char_("0123456789"), Hyp is char_('.'), and dot_ is '.'.
>>>
>>> template<typename It>
>>> struct DomainNameParser : boost::spirit::qi::grammar<It, Ast::Address()> {
>>>
>>>   DomainNameParser() {
>>>
>>>     _hyp = char_('-');
>>>     _dig = char_(DOMAIN_NAME_PARSER_DIGITS);
>>>     _let = char_(DOMAIN_NAME_PARSER_LOWERCASE DOMAIN_NAME_PARSER_UPPERCASE);
>>>
>>>     // A straight interpretation of the Domain Name grammar leads me to this:
>>>     /*qi::rule<It, std::string()>*/ _label = raw[_let >> -(*(_let |
>>> _dig | _hyp) >> (_let | _dig))];
>>>     /*qi::rule<It, Ast::Address()>*/ _start = (_label % dot_) >> eoi;
>>>     // ...
>>>
>>>  }
>>> };
>>>
>>> Assuming,
>>>
>>> struct Address {
>>>   std::vector<std::string> _labels;
>>> };
>>>
>>> BOOST_FUSION_ADAPT_STRUCT(Ast::Address,
>>>     (std::vector<std::string>, _labels)
>>> )
>>>
>>> However, this is failing to match: "E-PHUMZ8G8j1KEZG26C" in spite of
>>> the fact this matches the expected pattern. No skippers involved, just
>>> the iterator (std::string::const_iterator), and the AST, of course.
>>>
>>> For now, dropping the semantic action until I can get the parser to
>>> work properly. However, eventually I want to incorporate the
>>> validation rule:
>>>
>>> struct label_validation {
>>>     // Notwithstanding Qi/Fusion bits that glue it together.
>>>     bool operator()(std::string const& l) const {
>>>         return l.length() <= 63;
>>>     }
>>> };
>>>
>>> Once again I am suspicious whether Optional is working properly, never
>>> minding Kleene Star productions. I ended up needing to separate out
>>> Alternative phrases instead of the Optional before in order to make it
>>> work properly.
>>>
>>> Perhaps I need to capture each phrase in a rule of its own focused
>>> solely on std::string or char, respectively, as contrasted with the
>>> entire std::string?
>>
>> Here's an MRP:
>>
>> https://wandbox.org/permlink/cbpUPMnQ4APZeDdw
>
> I tried a little bit different version, IMO a little closer to the RFC
> if not exactly:
>
> https://wandbox.org/permlink/1sDTqnFphTA2egDu
>
> Notwithstanding the roll up in to std::vector of std::string, and
> ultimately ast::address.
>
>> More or less based on RFC 1034: https://tools.ietf.org/html/rfc1034#section-3.5
>>
>> Thoughts?

I decided to "simplify" in terms of the grammar rules themselves just a bit:

https://wandbox.org/permlink/I6qWWxp3urd1Q9wD

I figure the specifics of a grammatically correct label can be validated for:

1) specific content (first letter, last character, everything in between)
2) length of content

With that in mind, it is possible to introduce semantic actions
performing this label verification? Either two, or a single one
performing both, if necessary.

The Fusion functional strategy seems appealing, but I was unable to
get that to work quite right at compile time. Willing consider other
approaches to the same.

>> Cheers,
>>
>> Michael
>>
>>> Cheers,
>>>
>>> Michael Powell

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.