do not attempt to havoc void-typed objects; fixes issue #2663 #2735
Conversation
kroening
requested review from
peterschrammel,
pkesseli,
smowton and
tautschnig
as code owners
| @@ -271,7 +271,8 @@ class havoc_generate_function_bodiest : public generate_function_bodiest, | |||
| if( | |||
| parameter.type().id() == ID_pointer && | |||
| std::regex_match( | |||
| id2string(parameter.get_base_name()), parameters_to_havoc)) | |||
| id2string(parameter.get_base_name()), parameters_to_havoc) && | |||
| parameter.type().subtype().id() != ID_empty) | |||
There was a problem hiding this comment.
I think this should instead fall back to char, doing whatever would happen if the parameter were of type char*. Leaving the pointed-to object unmodified may fail to meet the user's expectations.
There was a problem hiding this comment.
I'd say that the user's expectation will be that the entire object that the 'void *' points to gets havoc'ed. 'char' seems arbitrary.
There was a problem hiding this comment.
So should we just refuse to generate code? Most cases using void * as parameter type will accept more than a single object type (e.g., arrays of varying length).
|
After some further discussion with @polgreen: in the same way that void pointers are skipped, so should be function pointers. |
kroening
force-pushed
the
fix-havoc-params
branch
from
c8642dc to
7c4a98a
Compare
|
Indeed, done. |
kroening
force-pushed
the
fix-havoc-params
branch
from
7c4a98a to
d02cf30
Compare
There was a problem hiding this comment.
Passed Diffblue compatibility checks (cbmc commit: d02cf30).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/85620044
|
Hi @kroening, is this PR still relevant? If yes, can we get it rebased on |
|
Closing due to age (no further comment on PR content), please reopen with rebase on develop if you intent to continue this work. |
No description provided.