Correct - and
CONFD_DAEMON_FLAG_STRINGSONLY predates the possibility to do generic value -> string translation in the library via
confd_val2str() - i.e. if
confd_val2str() had been first,
CONFD_DAEMON_FLAG_STRINGSONLY would never have been implemented...
The generiic way is to get the
struct confd_type* from the
struct confd_cs_node* for the leaf you have a value for, and find the
struct confd_cs_node* via the path to the leaf. And you "should" always have that path already, either as the "string path" that you passed to e.g.
confd_cs_node_cd() to find the node) or as a
confd_hkeypath_t* that you received in the
iter() callback for
confd_find_cs_node() to find the node). It's basically just 2 lines of code, e.g.:
struct confd_cs_node *csp = confd_cs_node_cd(NULL, path);
confd_val2str(csp->info.type, &v, buf, sizeof(buf));
It would be quite problematic if it printed "3" - you could have a YANG union of enumeration and e.g. int32, in which case it would be impossible to tell the difference between the 4th enum and the integer 3. (And if you at some point wanted to translate it back to an internal value, it would always be the integer.)
You could implement something like that fairly trivially by using
confd_serialize() and then your favorite stringification method on the binary buffer produced - e.g. hex or base64.
I would recommend the