>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/arm/display/komeda/komeda_dev.c?id=c4b9850b3676869ac0def5885d781d17f64b3a86#n222 >> >> … >> @@ -222,… @@ struct komeda_dev *komeda_dev_create(str >> >> clk_prepare_enable(mdev->aclk); >> >> - mdev->funcs = product->identify(mdev->reg_base, &mdev->chip); >> if (!komeda_product_match(mdev, product->product_id)) { >> … >> mdev->funcs->init_format_table(mdev); >> >> err = mdev->funcs->enum_resources(mdev); >> … >> >> >> Now I would appreciate once more if the description for the supported >> software behaviour can be completed for the safe usage of SmPL >> code exclusion specifications. … > I have no idea what you are asking about here.
I hope that another wording approach can contribute another bit to a better common understanding of the involved source code analysis expectations. > Are you concerned that you don't know the return type of > mdev->funcs->init_format_table? No, not in this test case. This member function is declared with the return type “void”. https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/gpu/drm/arm/display/komeda/komeda_dev.h#L83 https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/arm/display/komeda/komeda_dev.h?id=c4b9850b3676869ac0def5885d781d17f64b3a86#n94 I would find this function call questionable otherwise. The desired function is determined over the pointer “mdev->funcs” which was provided by a call of the function “product->identify(…)”. The provided function pointer is actually not directly checked after the data structure member assignment. This could be an analysis concern. (But it can be determined by inspection of involved source files that a valid pointer will probably be set. I assume that the exclusion of null pointers would be too challenging for the discussed tiny SmPL script.) The uncertainty around the partly (un)documented software behaviour for SmPL when constraints makes it unclear then if the presented source code place should finally be treated as a false positive. Should it have been excluded because pointer expressions should be detectable for the metavariable “y” (a bit later)? Regards, Markus _______________________________________________ Cocci mailing list [email protected] https://systeme.lip6.fr/mailman/listinfo/cocci
