[MDSAL-361] Deal with restricted types in unions Created: 04/Jul/18 Updated: 18/Jan/24 |
|
| Status: | Confirmed |
| Project: | mdsal |
| Component/s: | Binding codegen |
| Affects Version/s: | None |
| Fix Version/s: | 14.0.0 |
| Type: | Bug | Priority: | Medium |
| Reporter: | Robert Varga | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Description |
|
A typical example of a union which we do not handle correctly is:
typedef pce-id {
type union {
type binary {
length 4;
}
type binary {
length 16;
}
}
}
These types are restricted and guaranteed not to overlap, but our current codegen rules silently squash them to a single field (first one wins, I think). There are multiple approaches we could take, like squashing the definitions, but that would only serve to confuse users – in this particular case they would be better served by generating encapsulated types for member – i.e. similar to what we do for enumerations. We need to figure out the naming here – as we cannot just take the 'binary' string – that would result in conflicting names. That naming clash needs to be figured out also for something like:
typedef pce-id {
type union {
type enumeration {
enum a;
}
type enumeration {
enum b;
}
}
}
|
| Comments |
| Comment by Robert Varga [ 04/Oct/18 ] |
|
https://git.opendaylight.org/gerrit/#/c/76057/ needed to be reverted, as it just breaks with:
typedef route-distinguisher {
type union {
// type 0: <2-byte administrator>:<4-byte assigned number>
type string {
pattern "(65[0-5][0-3][0-5]|[1-5][1-5][0-9][0-9][0-9]|"
+ "[1-9]?[1-9]?[0-9][0-9]|[1-9]):"
+ "(4[0-2][0-9][0-4][0-9][0-6][0-7][0-2][0-9][0-5]|"
+ "[0-3][0-9]{9}|[1-9][0-9]{1,8}|[1-9])";
}
// type 1: <ip-address>:<2-byte assigned number>
type string {
pattern
"(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}"
+ "([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]):"
+ "(65[0-5][0-3][0-5]|[1-5][1-5][0-9][0-9][0-9]|"
+ "[1-9]?[1-9]?[0-9][0-9]|[1-9])";
}
// type 2: <4-byte as-number>:<2-byte assigned number>
type string {
pattern
"(4[0-2][0-9][0-4][0-9][0-6][0-7][0-2][0-9][0-5]|"
+ "[0-3][0-9]{9}|[1-9][0-9]{1,8}|[1-9]):"
+ "65[0-5][0-3][0-5]|[1-5]{2}[0-9]{3}|"
+ "[1-9]{0,2}[0-9][0-9]|[1-9])";
}
}
description "A route distinguisher value";
reference "RFC4364";
}
This effectively means we cannot just squash these types to String and enforce them, but need to generate a proper (nested) class which will represent them. This is not 3.0.0 material, punting to next release. |
| Comment by Robert Varga [ 17/Dec/19 ] |
|
This has been seen in the wild, hence reclassifying as a bug. We will need to address this in a minimally-breaking way, so that the mechanics here kicks in only in the case of a conflict. |