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

YANG parser generates invalid code for compound data structures #1419

Open
alexandergall opened this issue Feb 14, 2019 · 0 comments
Open

YANG parser generates invalid code for compound data structures #1419

alexandergall opened this issue Feb 14, 2019 · 0 comments
Labels

Comments

@alexandergall
Copy link
Contributor

Consider the schema

module yang-afi {
  namespace foo;
  prefix foo;
  
  import ietf-inet-types { prefix inet; }
  
  container address-families {
    presence "foo";
    container ipv4 {
      leaf address {
        type inet:ipv4-address;
        mandatory true;
      }
      leaf next-hop {
        type inet:ipv4-address;
        mandatory true;
      }
    }
    container ipv6 {
      presence "foo";
      leaf address {
        type inet:ipv6-address;
        mandatory true;
      }
      leaf next-hop {
        type inet:ipv6-address;
        mandatory true;
      }
    }
  }
}

This should create a container with two optional sub-containers which each contain two mandatory leafs (without presence, the ipv4 and ipv6 containers would be mandatory due to the mandatory ancestors).

Application of the schema to the data

address-families {
  ipv4 {
    address "10.0.0.1";
    next-hop "10.0.0.2";
  }
}

with

local yang = require("lib.yang.yang")

yang.add_schema_file("yang-afi.yang")
local config = yang.load_configuration("yang-afi.config", {  schema_name = "yang-afi" })

produces an internal error

ERROR: While parsing type:
ERROR:   struct { struct { struct { uint32_t address; uint32_t next_hop; } ipv4; struct { uint8_t address ipv6 address_families[16]; uint8_t next_hop[16]; }; }; }
ERROR:                                                                                                                                                         ^
ERROR: bad member name

Clearly, there should be the member name ipv6 included in this ctype definition.

I also suspect that even if the member name is produced correctly, this will actually create a parser for which both containers are mandatory, but I'm not sure about that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant