uninitialized variable

uninitialized variable

[John Regehr]

This call:

regcomp(&r, "^(b+|||(CW*)*|){5,}{53}*+)^?5,}", REG_EXTENDED);

ends up using uninitialized memory like so:

regcomp.c:221:[kernel] warning: accessing uninitialized left-value:
                   assert \initialized(&right->num_submatches);
                   stack: tre_ast_new_catenation :: regcomp.c:1764 <-
                          tre_copy_ast :: regcomp.c:1916 <-
                          tre_expand_ast :: regcomp.c:2771 <-
                          musl_regcomp :: foo.c:9 <-
                          main

Having crap in this field seems bad since it is used to compute a malloc 
size.

John

Re: uninitialized variable

[Szabolcs Nagy]

* John Regehr <regehr@cs.utah.edu> [2016-05-19 17:28:58 +0200]:
> This call:
> 
> regcomp(&r, "^(b+|||(CW*)*|){5,}{53}*+)^?5,}", REG_EXTENDED);
> 
> ends up using uninitialized memory like so:
> 
> regcomp.c:221:[kernel] warning: accessing uninitialized left-value:
>                   assert \initialized(&right->num_submatches);
>                   stack: tre_ast_new_catenation :: regcomp.c:1764 <-
>                          tre_copy_ast :: regcomp.c:1916 <-
>                          tre_expand_ast :: regcomp.c:2771 <-
>                          musl_regcomp :: foo.c:9 <-
>                          main

thanks

it seems tre_add_tag* allocates a node
without initializing this field.

(nodes are supposed to be allocated by
dedicated functions based on node type,
those do the init.)

it seems this is wrong in the original tre
code too.

the ere "(a){2,}" should touch that code path.

i guess the right fix is to set the field
to 0, but i will have to look at the logic
more.

> 
> Having crap in this field seems bad since it is used to compute a malloc
> size.
> 
> John