Hi Dave, Thanks for the confirmation about the expected type argument, I will add it in the shared layer.
While going through the current analyzer implementation, I noticed that arguments to the function calls are retrieved through *call_details::get_arg_svalue()* and then handles as const svalue*, rather than *tree* nodes like in the frontend and GIMPLE passes. From what I can understand, the library calls behaviour is modelled through *known_function* handlers interacting with the *region_model*(for example through *impl_call_pre in kf_ handlers*), and then the existing checks for functions like printf are mostly driven by format attribute and the validation of format string arguments(for example using *check_for_null_terminated_string_arg()*), instead of interpreting the individual directives. But one thing that I am not sure about is where the shared string-parser show be integrated on the analyzer side. Maybe it should be triggered through the attribute-based path , or it is better to use it inside the individual kf_* handlers for the functions like printf-style. Also, before starting to draft the official proposal, I wanted to confirm the expected size of this project. From my current understanding, it would be 350 hours, dividing this project into 2 major phases, the first phase of the project to unify the parsing logic among all 3 subsystems and the second phase to be the actual work on the analyzer part. Please let me know if it matches your expectations or would you prefer 175 hour scope? Best, Ridham Khurana
