Smart Init: the type conversion information was incorrectly calculated.

[zenhumany]

Hi, Tomasz
@tkuchta
Thank you for open sourcing such an excellent project.I found an issue in the actual test.Details are as
follows.

1. demo code
1459 char *
1460 ngx_conf_check_num_bounds(ngx_conf_t *cf, void *post, void *data)
1461 {
1462 ngx_conf_num_bounds_t *bounds = post;
1463 ngx_int_t *np = data;
1464
1465 if (bounds->high == -1) {
1466 if (*np >= bounds->low) {
1467 return NGX_CONF_OK;
1468 }
1469
1470 ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
1471 "value must be equal to or greater than %i",
1472 bounds->low);
1473
1474 return NGX_CONF_ERROR;
1475 }
1476
1477 if (*np >= bounds->low && *np <= bounds->high) {
1478 return NGX_CONF_OK;
1479 }
1480
1481 ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
1482 "value must be between %i and %i",
1483 bounds->low, bounds->high);
1484
1485 return NGX_CONF_ERROR;
1486 }

2. _parse_derefs_trace return error cast info
(Pdb) p str(ret_val[0][1])
"[TypeUse] id = 0 t_id = 911 original_tid = 912 is_pointer = True name = 'ngx_conf_t' offsetof_types = [] contained_types = [] used_members = {} cast_types = []"
(Pdb) p str(ret_val[1][1])
"[TypeUse] id = 1 t_id = 1949 original_tid = 1949 is_pointer = True name = 'ngx_conf_num_bounds_t *' offsetof_types = [] contained_types = [] used_members = {} cast_types = [(0, 22, True,
(Pdb) p str(ret_val[2][1])
"[TypeUse] id = 2 t_id = 1949 original_tid = 1949 is_pointer = True name = 'ngx_conf_num_bounds_t *' offsetof_types = [] contained_types = [] used_members = {} cast_types = [(0, 22, True)]"

parameter 1 "post" casted to 'ngx_conf_num_bounds_t'
parameter 2 "data" casted to 'ngx_int_t', but the _parse_derefs_trace think the parameter should be cast to 'ngx_conf_num_bounds_t' type.

3. root cause
The smart init algorithm only focuses on the conversion between types when performing data flow analysis, and does not consider the relationship between variables corresponding to types.

[tkuchta]

Hello @zenhumany,
Thank you for your interest in auto_off_target.
The algorithm used in smart init is a lightweight heuristic. More details on which features it looks at can be found in the paper: https://dl.acm.org/doi/pdf/10.1145/3551349.3556915, section 3.4.

The algorithm used currently is a tradeoff between keeping the analysis relatively lightweight and still being able to handle many cases correctly. The downside of this approach is that type mismatches as you reported might occur. I think the difficulty for the algorithm here is that we have 2 void* arguments, both casted to different types.

We plan to further develop smart init to capture more cases. Ideally it would turn into a more precise static analysis engine, but that is a considerably larger effort.
In any case, ideas, suggestions and PRs are welcome.

In the meantime I would suggest to manually modify the generated OT code to correct the type.

[zenhumany]

Understood, thanks for your reply.