Repository navigation
Assign implicit enum values after the highest value, even when negative - #317
Open
thomas-mangin wants to merge 1 commit into
Open
thomas-mangin wants to merge 1 commit into
thomas-mangin wants to merge 1 commit into
Conversation
RFC 7950 section 9.6.4.2: If the enum substatement is the first one
defined, the assigned value is zero (0); otherwise, the assigned value
is one greater than the current highest enum value.
EnumType.last starts at -1 so that the first implicit value is 0, but
Set only replaced it with a value of at least -1. After an explicit
negative first value the next implicit value was 0 instead of one
greater than that value. The module fragment
enum p { value -5; } enum q; enum r { value 0; }
was refused with: fields r and q conflict on value 0. An enumeration of
only negative values gave its implicit member the value 0.
Set now records the first assigned value unconditionally and any later
value greater than the current highest one.
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Author
|
I have signed the CLA |
thomas-mangin
added a commit
to ze-software/ze
that referenced
this pull request
Oct 9, 2026
goyang v1.6.3 numbered an enum with no value after a negative value from
0, against RFC 7950 Section 9.6.4.2 ("otherwise, the assigned value is
one greater than the current highest enum value"), so Loader.Resolve
refused the valid enum p { value -5; } enum q; enum r { value 0; } with:
fields r and q conflict on value 0. The fix is proposed upstream in
openconfig/goyang#317; go.mod replaces goyang
with github.com/ze-software/goyang v1.6.4-0.20261009101552-a3cf525c4f98
until a release carries it.
The vendor tree is updated by hand, for goyang only, because go mod
vendor would revert the hand-patched vishvananda/netlink from
f0d9c75. go.sum changes only the goyang lines. The fork is cut from
upstream master a80f279, so upstream's must-deviation and dup()
Extra-copy changes in entry.go ride along.
TestGoyangNumbersAnEnumAfterANegativeValue loads the module through
AddModuleFromText and Resolve: red on v1.6.3, green with the fork.
Comments and yang-config-design.md no longer claim goyang misnumbers;
journal row 4 is closed. The independent judge re-read RFC7950-9.6.4.2-1
(rfc/audit/rfc7950.json): it stays weak until a tagged positive loads
the module, a follow-up named in the handover.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
RFC 7950 section 9.6.4.2: "If the "enum" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest enum value".
EnumType.laststarts at -1 so the first implicit value is 0, butSetonly replaced it with a value >= -1. After an explicit negative first value, the next implicit value was 0 instead of one greater than that value. Sois refused with
fields r and q conflict on value 0(q should be -4), and an enumeration of only negative values gives its implicit member 0.Setnow records the first assigned value unconditionally, then any greater value. TwoTestTypeResolvecases cover it (implicit value after -5 followed by an explicit 0; only negative values). Both fail before the change;go test ./...passes after it.