I have an encode function that populates the confd_tag_value_t in find_next_object and get_next_object callbacks.
This encode function takes integer as an argument and uses a switch-case to map the integer to a corresponding string which is then set to the confd_tag_value_t pointer.
But the show command displays an empty field for this column, except a few rows.
Relevant code snippet:
int my_tracer_encode(struct confd_trans_ctx *tctx, confd_tag_value_t *p_val, int tid, trace_t *trace)
{
int curr_elem = 0;
char trace_str[64];
get_trace_str(trace->id, trace_str); // this implements a switch case that maps id to str.
/* I have tried to printf the value of trace_str here and prints fine. */
CONFD_SET_TAG_UINT16(&p_val[curr_elem++], tracer_trace_id, tid);
CONFD_SET_TAG_STR(&p_val[curr_elem++], tracer_trace_str, trace_str);
return curr_elem;
}
You do not explicitly show how you set/print your C_STRtrace_str - so i cannot infer whether it is correctly null terminated…
There is some brief info in man confd_types page (or UG) regarding C_STR, and C_BUF.
In general, C_BUF is the primary data type for string. You still can use C_STR in callbacks etc. (see man page), but must guarantee null termination.
It depends on the procedures/data format you have for processing. Generally it’s cleaner/safer to work with C_BUF type (str + length) of string, compared to C_STR (null-terminated str only).
(similarly how e.g. in general C strcpy() is not recommended, rather strncpy())
edit:
just noticed that, if you use the function exactly as typed in above comment, you have obvious C bug:
you declare char trace_str[64] on stack
you reference this memory in p_val
you exit function my_tracer_encode,
stack is most possibly invalidated, leaving you with corrupted data that originally resided at trace_str
(CONFD_SET_TAG_STR() and all the other similars are just macros that assign pointers/primitive types, but do not copy static/dynamic memory blocks in any way)