commit 7b191ce81ef6006c868d8be5d19970cd0fafe35b
author Václav Kubernát <kubernat@cesnet.cz> Tue Jun 30 16:22:53 2020 +0200
committer Václav Kubernát <kubernat@cesnet.cz> Thu Jul 02 16:07:55 2020 +0200
tree 3abad35b8399db95a570852d03f0142cf6734f85
parent e5df98f8861bc3c243988ed04c396b954c32203c

Fix crashes on leafref value printing

Okay. Right. Yeah. So...

Look at the test change: what I'm doing is retrieving
"/example-schema:bossPerson". Okay, so bossPerson is a leafref. Alright.

Now, let's look at how impl_lyNodesToTree worked before this patch.
It takes leaf.value() and leaf.value_type->base() and tries to convert
that into leaf_data_. Now, let's say `leaf` in this case is our
bossPerson. So we take its value() and leaf_type.base().
leaf_type.base() always tells the underlying type even through leafrefs
and union so in this case it is STRING, because bossPerson person points
to "/example-schema:person/name" and that is a string. Everything is
fine until now.

What I've found is, that there are (at least) two ways to store values,
which are leafrefs. The first one is straightforward - you use
value().leafref() to get the data node our node points to, and then you
can go all the way, until you find something that is not leafref.  Query
that node's value and bam, you have your value (which would be of type
STRING in the case of bossPerson).

However, something is kind of weird: if that is how I'm supposed to
retrieve leafref values, how come I never call this leafref() method in
`leafValueFromValue`? When I added the test I was surprised that when
dealing with bossPerson, the function worked fine. How? Well...

There is apparently another way to store leafref values and that is
DIRECTLY under the base type inside the leafref you have at the start.
That's the reason the netconf test worked just like that. I suppose if
you're retrieving just bossPerson and the other stuff, there's nothing
to point to and libyang just stores the string.

However, when using YangAccess, I do have access to the pointed-to
leafs. So in that case, the value isn't stored directly, but inside the
pointed-to leafs (because they are available). This is where the bug
came from: the libyang::Value class stored, but I pass a STRING base
type to `leafValueFromValue`. Libyang finds this mismatch and throws. So
how do I check what exactly am I dealing with?

Welp, the internal type can be queried by
Data_Node_Leaf_List::value_type, so pass that instead of the base type.

Some more info: https://github.com/CESNET/libyang/issues/1135

Change-Id: I46043e101a47fd8b11b8e2121fdf21fd73ce7cdc