Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ietf-inet-types@2020-07-06.yang parsing #180

Closed
idefixcert opened this issue May 17, 2021 · 0 comments · Fixed by #181
Closed

ietf-inet-types@2020-07-06.yang parsing #180

idefixcert opened this issue May 17, 2021 · 0 comments · Fixed by #181

Comments

@idefixcert
Copy link
Contributor

Hello,
thanks for this wonderful library.
we are using it for code generation.

I am struggling when parsing the ietf-inet-types@2020-07-06.yang file.

in particular:

  typedef email-address {
    type string {
      // dot-atom-text "@" ...
      pattern '[a-zA-Z0-9!#$%&'+"'"+'*+/=?^_`{|}~-]+'
            + '(\.[a-zA-Z0-9!#$%&'+"'"+'*+/=?^_`{|}~-]+)*'
            + '@'
            + '[a-zA-Z0-9!#$%&'+"'"+'*+/=?^_`{|}~-]+'
            + '(\.[a-zA-Z0-9!#$%&'+"'"+'*+/=?^_`{|}~-]+)*';
    }
    description
      "The email-address type represents an email address as
       defined as addr-spec in RFC 5322 section 3.4.1.";
    reference
      "RFC 5322: Internet Message Format";
  }

This causes 6 errors:
etf-inet-types@2020-07-06.yang:548:36: +'*+/=?^_`: syntax error
ietf-inet-types@2020-07-06.yang:548:46: {: not an identifier
ietf-inet-types@2020-07-06.yang:548:48: }: syntax error
ietf-inet-types@2020-07-06.yang:549:15: (.[a-zA-Z0-9!#$%&': syntax error
ietf-inet-types@2020-07-06.yang:549:51: }: syntax error
ietf-inet-types@2020-07-06.yang:550:15: @[a-zA-Z0-9!#$%&': syntax error

But if I read https://datatracker.ietf.org/doc/html/rfc7950#section-6.1.3.1 correct than
'[a-zA-Z0-9!#$%&'+"'"+'*+/=?^_{|}~-]+'`
are 3 strings concatenated by +.

wenovus added a commit that referenced this issue Jun 19, 2021
…er a concatenation (plus sign).

This code makes the new assumption that a `'` that follows `+` must be a string.

This change will break YANG files where there exists an unquoted string that contains a `+'` character substring. Given that this is unlikely, I think this is a fine tradeoff to get cases like #180 working.

Indeed, the current lexer is already assuming `"` cannot exist within an unquoted string (see `lexIdentifier`). This is already a much more restrictive assumption.

NOTE: In YANG1.1:
```
An unquoted string cannot contain any single or double quote
      characters.
```

Fixes #180.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant