-
Notifications
You must be signed in to change notification settings - Fork 273
smt2_solver: implement (echo "string") #3463
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
Passed Diffblue compatibility checks (cbmc commit: 0fdf8ee).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/92466982
I assume a test will come... |
@@ -185,8 +208,6 @@ void smt2_solvert::command(const std::string &c) | |||
| ( define-fun-rec hfunction_def i ) | |||
| ( define-funs-rec ( hfunction_deci n+1 ) ( htermi n+1 ) ) | |||
| ( define-sort hsymboli ( hsymboli ??? ) hsorti ) | |||
| ( echo hstringi ) | |||
| ( exit ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is exit
deleted here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated cleanup
src/solvers/smt2/smt2_solver.cpp
Outdated
@@ -162,6 +178,13 @@ void smt2_solvert::command(const std::string &c) | |||
std::cout << e.pretty() << '\n'; // need to do an 'smt2_format' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, just noticed this one: we already have smt2_format
by now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, yes, as of #3461. Will tweak.
src/solvers/smt2/smt2_solver.cpp
Outdated
if(next_token() != STRING_LITERAL) | ||
std::cout << "expected string literal" << '\n'; | ||
else | ||
std::cout << smt2_string_literal(buffer) << '\n'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems errors and desired output are indistinguishable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs #3441
src/solvers/smt2/smt2_solver.cpp
Outdated
if(c == '"') | ||
result += "\"\""; | ||
else | ||
result += c; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about replace_all
from string_utils.{h,cpp}?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uh, actually, that's implemented in a really inefficient way when the string gets longer. Let's say separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find it quite brave that a character-by-character operator+=
on a string is used in an argument about efficiency. Also I wonder whether anyone uses echo
with long strings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The loop in smt2_string_literal is quasi linear (assuming a standard allocation strategy), despite the +=.
The one in replace_all is quadratic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you say "standard allocation strategy" what is it that you are assuming? Growing by some factor > 1? That at least does not seem to be the case with the STL implementation shipped with GCC 8, which just increases the allocation by the size of the string being appended.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this refers to the ability of the allocator to avoid fragmentation; the threat is that this becomes quadratic if there's a non-trivial number of re-allocations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wrong in my previous comment, _M_create
actually does exponential growth of the allocation. So we should just fix replace_all
.
0fdf8ee
to
a1fe6d4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
Passed Diffblue compatibility checks (cbmc commit: a1fe6d4).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/92910569
a1fe6d4
to
f59fc6e
Compare
Now with test! |
97980ec
to
f59fc6e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✔️
Passed Diffblue compatibility checks (cbmc commit: f59fc6e).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/92992375
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚫
This PR failed Diffblue compatibility checks (cbmc commit: 97980ec).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/92994410
Status will be re-evaluated on next push.
Please contact @peterschrammel, @thk123, or @allredj for support.
Common spurious failures:
- the cbmc commit has disappeared in the mean time (e.g. in a force-push)
- the author is not in the list of contributors (e.g. first-time contributors).
The incompatibility may have been introduced by an earlier PR. In that case merging this
PR should be avoided unless it fixes the current incompatibility.
Test to be added.