On 6/18/24 17:33, Wasser Mai wrote:
> diffutils-3.10/src/util.c:687:3: alloc_fn: Storage is returned from
> allocation function ""xstrdup"".
> diffutils-3.10/src/util.c:687:3: var_assign: Assigning: ""color_buf""
> = storage returned from ""xstrdup(p)"".
> diffutils-3.10/src/util.c:687:3: var_assign: Assigning: ""buf"" = ""color_buf"".
> diffutils-3.10/src/util.c:795:1: leaked_storage: Variable ""buf""
> going out of scope leaks the storage it points to.
> diffutils-3.10/src/util.c:795:1: leaked_storage: Variable
> ""color_buf"" going out of scope leaks the storage it points to.

Yes I saw that too, but some of that storage might be addressed by the 
pointers in color_indicator; see the assignment 
"color_indicator[ind_no].string = buf". So that particular diagnostic is 
a false positive.

In looking at this code in more detail, though, we should be able to 
pacify Coverity (and also fix a true memory leak nearby, which Coverity 
didn't notice) by reworking the code to not call malloc either directly 
or indirectly via xstrdup. I installed the attached patch to do that.

None of this is a big deal, as hardly anybody uses the --color-palette 
option and the true memory leaks are small and rare even when 
--color-palette is used.