CONFD_SET_TAG_STR not printing the string


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;


  leaf trace-str {
    tailf:info "Trace string";
    type string;
    tailf:cli-column-width "15";

Please suggest what could be going wrong.

You do not explicitly show how you set/print your C_STR trace_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())

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)

Thanks, Joseph!
Moving the trace_str out of stack resolved the problem.