ietf-inet-types union usage (ordering inside unions)

[NLako-6WIND]

Hello,

I have a question about the expected behavior when using unions, here is an example file:

module ipv4union {
	yang-version 1.1;
	namespace "urn:ipvunion";
	prefix e;
	import ietf-inet-types {
	       prefix inet;	
	}

	leaf myaddr {
		type union {
			type inet:ipv4-prefix;
			type inet:ipv4-address-no-zone;
		}
		description "An IPv4 address that could be with or without the prefix.";
	}
}

And two simple configs:

$ cat ipv4_no_prefix.xml
<myaddr xmlns="urn:ipvunion">192.168.1.1</myaddr>

$ cat ipv4_prefixed.xml
<myaddr xmlns="urn:ipvunion">192.168.1.1/24</myaddr>

When editing the myaddr leaf, the behavior may differ, depending on the ordering of types inside the union.

$ sysrepocfg --import=ipv4_no_prefix.xml --datastore running --module ipv4union --format xml
$ sysrepocfg --export --datastore running --module ipv4union --format xml
<myaddr xmlns="urn:ipvunion">0.0.0.0/0</myaddr> # <<< The address is treated as an ipv4-prefix, with a prefix of 0

$ sysrepocfg --import=ipv4_prefixed.xml --datastore running --module ipv4union --format xml
$ sysrepocfg --export --datastore running --module ipv4union --format xml
<myaddr xmlns="urn:ipvunion">192.168.1.0/24</myaddr>

$ sysrepoctl --uninstall ipv4union
#
### Changing the order of types in the union such as:
#		type union {
#			type inet:ipv4-address-no-zone;
#			type inet:ipv4-prefix;
#		}
#
$ sysrepoctl -i ipv4union.yang

$ sysrepocfg --import=ipv4_no_prefix.xml --datastore running --module ipv4union --format xml
$ sysrepocfg --export --datastore running --module ipv4union --format xml
<myaddr xmlns="urn:ipvunion">192.168.1.1</myaddr> # <<< The address is treated as is

$ sysrepocfg --import=ipv4_prefixed.xml --datastore running --module ipv4union --format xml
$ sysrepocfg --export --datastore running --module ipv4union --format xml
<myaddr xmlns="urn:ipvunion">192.168.1.0/24</myaddr>

So, is the ordering of unions important and should be considered? or is this a bug?

Previously, I was using libyang 3.13.3, and the behavior was always same as in the second case.
Locally reverting some changes made in 78067fc591f solves the issue and recover the initial behavior:

index 5a55a739eccc..1e2d946e8248 100644
--- a/src/plugins_types/ipv4_prefix.c
+++ b/src/plugins_types/ipv4_prefix.c
@@ -128,6 +128,7 @@ lyplg_type_store_ipv4_prefix(const struct ly_ctx *ctx, const struct lysc_type *t
         struct lyd_value *storage, struct lys_glob_unres *UNUSED(unres), struct ly_err_item **err)
 {
     LY_ERR ret = LY_SUCCESS;
+    struct lysc_type_str *type_str = (struct lysc_type_str *)type;
     struct lyd_value_ipv4_prefix *val;
     uint32_t value_size;
 
@@ -164,6 +165,10 @@ lyplg_type_store_ipv4_prefix(const struct ly_ctx *ctx, const struct lysc_type *t
     ret = lyplg_type_check_hints(hints, value, value_size, type->basetype, NULL, err);
     LY_CHECK_GOTO(ret, cleanup);
 
+    /* pattern restrictions */
+    ret = lyplg_type_validate_patterns(ctx, type_str->patterns, value, value_size, err);
+    LY_CHECK_GOTO(ret, cleanup);
+
     /* get the mask in network-byte order */
     ret = ipv4prefix_str2ip(value, value_size, &val->addr, &val->prefix, err);
     LY_CHECK_GOTO(ret, cleanup);

[michalvasko]

Yes, the order does matter according to the definition. And there was actually a bug for a long time when the patterns of a type were not validated as should have been (too aggressive optimizations some time ago).

[NLako-6WIND]

Thanks for the response about the orders of types in unions.

It seems to me, that there is still a bug with the pattern validation today, at least for ipv[4|6]-prefixes.
The RFC9911 ipv4-prefix pattern require the presence of the prefix (/xx).
In the first example above, the provided data is stored as an ipv4-prefix, but it shouldn't as it doesn't match the ipv4-prefix regex, and should be stored as an ipv4-address-no-zone instead.