Comment 6 for bug 1716113

That is the backtrace of the call adding the "00"

#0 write () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007f2160fa4917 in _IO_new_file_write (f=0x7f21612ea600 <_IO_2_1_stdout_>, data=0x7f21612ea683 <_IO_2_1_stdout_+131>, n=1)
    at fileops.c:1271
#2 0x00007f2160fa6462 in new_do_write (to_do=1, data=0x7f21612ea683 <_IO_2_1_stdout_+131> "", fp=0x7f21612ea600 <_IO_2_1_stdout_>)
    at fileops.c:526
#3 _IO_new_do_write (fp=fp@entry=0x7f21612ea600 <_IO_2_1_stdout_>, data=0x7f21612ea683 <_IO_2_1_stdout_+131> "", to_do=1) at fileops.c:502
#4 0x00007f2160fa693b in _IO_new_file_overflow (f=0x7f21612ea600 <_IO_2_1_stdout_>, ch=0) at fileops.c:867
#5 0x00007f2160f9c810 in putchar (c=c@entry=0) at putchar.c:28
#6 0x000000010000af54 in printf (__fmt=<synthetic pointer>) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:104
#7 cprintf_pc (human=<optimized out>, num=5, wi=7, wd=2) at common.c:1329
#8 0x0000000100005bf8 in write_pid_task_cpu_stats (prev=0, curr=1, dis=<optimized out>, disp_avg=0, prev_string=<optimized out>,
    curr_string=0x7fffffffe0c0 "09:29:10", itv=200, g_itv=200) at pidstat.c:1645
#9 0x0000000100007c5e in write_stats_core (prev=0, curr=1, dis=1, disp_avg=0, prev_string=0x7fffffffe080 "09:29:03",
    curr_string=0x7fffffffe0c0 "09:29:10") at pidstat.c:2320
#10 0x0000000100007ed4 in write_stats (curr=1, dis=1) at pidstat.c:2432
#11 0x000000010000819a in rw_pidstat_loop (dis_hdr=1, rows=23) at pidstat.c:2528
#12 0x0000000100002518 in main (argc=3, argv=0x7fffffffe468) at pidstat.c:2845

That sequence is meant to normalize the color again after a former color output.
1328 printf("%s", sc_normal);
1329 printf("%c", u);

Frame 8 above does not condition check on color code being requested.
Instead there is "init_colors", but the logic there is odd:

/* Read S_COLORS environment variable */
if (((e = getenv(ENV_COLORS)) == NULL) ||
    !strcmp(e, C_NEVER) ||
    (strcmp(e, C_ALWAYS) && !isatty(STDOUT_FILENO))) {
=> then reset colors to "nothing"

But that is ?!?!
If the var is not found then it is supposed to be "auto" which means keep color codes - ok
If set to never it is supposed to reset them, but the !strcmp avoids just that - broken?.
Then if set to "always" but not a tty then reset the colors - ok, but ...
What if it is set to "auto" as documented in the man page, then it is supposed to disable on !isatty as well IMHO but it won't.

Then on the print it does:
1327 »···»···printf(" %*.*f", wi, wd, val); <- Value
1328 »···»···printf("%s", sc_normal); <- Color code (if set)
1329 »···»···printf("%c", u); <- '\0' in non human mode

So there are two things:
1. check if the color setting code is right and fix if needed
2. check if the '\0' follow up is our special char and if if it is so

writing some debug code now ...