Skip to content
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

Executor::getConstraintLog(), Interpreter::LogType and -write-cvcs needs a clean up #382

Closed
delcypher opened this issue Apr 29, 2016 · 4 comments
Labels

Comments

@delcypher
Copy link
Contributor

STP is no longer the only core solver in KLEE so we to clean up a few things

  • Replace Interpreter::LogType::STP with Interpreter::LogType::SOLVER_NATIVE_FORMAT
  • The -write-cvcs option should be changed to -write-native-solver-format (similarly for the corresponding variable name).
  • We shouldn't emit files using the .cvc extension. We either need to add a new method to the solver classes so that we can get the native format's file extension or we should be lazy and just emit .native_solver_format and let the user figure out what the extension should be.
@delcypher
Copy link
Contributor Author

This is very straight forward apart from handling the file extension? @ccadar @MartinNowack do you have any preferences on how to handle this?

@delcypher
Copy link
Contributor Author

Oh another idea. Change the interface of Solver::getConstraintLog() from

virtual char *getConstraintLog(const Query& query);

to

virtual char *getConstraintLog(const Query& query, std::string* logFileExtension);

if logFileExtension is not null then the string pointed to is changed to be the file extension for the format being emitted.

I don't like mixing char* and std::string* in the same interface but using char** for logFileExtension would require that we have a third parameter to state the size of the memory that logFileExtension points to, to avoid doing out of bounds access.

@ccadar
Copy link
Contributor

ccadar commented May 28, 2016

I prefer the variant where we generate proper extensions.

delcypher pushed a commit to delcypher/klee that referenced this issue Mar 23, 2017
There are numerous changes here which removes the assumption that
STP is the core solver.

* `-write-cvcs` has been renamed to `-write-core-solver-queries`
* `LogType::STP` has been renamed to `LogType::CORE_SOLVER_LANG`
* `Interpreter::getConstraintLog()` and `Executor::getConstraintLog()`
  now have a `fileExtension` parameter which returns the file extension
  for constraint language requested.
* The `Solver::getConstraintLog()` and `SolverImpl::getConstraintLog()`
  methods (and all their decendents) now have a `fileExtension`
  parameter which will be set (if requested by the client) to file the
  extension for the core solver's constraint language.
delcypher pushed a commit to delcypher/klee that referenced this issue Mar 23, 2017
There are numerous changes here which removes the assumption that
STP is the core solver.

* `-write-cvcs` has been renamed to `-write-core-solver-queries`
* `LogType::STP` has been renamed to `LogType::CORE_SOLVER_LANG`
* `Interpreter::getConstraintLog()` and `Executor::getConstraintLog()`
  now have a `fileExtension` parameter which returns the file extension
  for constraint language requested.
* The `Solver::getConstraintLog()` and `SolverImpl::getConstraintLog()`
  methods (and all their descendants) now have a `fileExtension`
  parameter which will be set (if requested by the client) to the
  file extension for the core solver's constraint language.
@delcypher delcypher mentioned this issue Mar 23, 2017
delcypher pushed a commit to delcypher/klee that referenced this issue Mar 23, 2017
There are numerous changes here which removes the assumption that
STP is the core solver.

* `-write-cvcs` has been renamed to `-write-core-solver-queries`
* `LogType::STP` has been renamed to `LogType::CORE_SOLVER_LANG`
* `Interpreter::getConstraintLog()` and `Executor::getConstraintLog()`
  now have a `fileExtension` parameter which returns the file extension
  for constraint language requested.
* The `Solver::getConstraintLog()` and `SolverImpl::getConstraintLog()`
  methods (and all their descendants) now have a `fileExtension`
  parameter which will be set (if requested by the client) to the
  file extension for the core solver's constraint language.
delcypher pushed a commit to delcypher/klee that referenced this issue Mar 23, 2017
There are numerous changes here which removes the assumption that
STP is the core solver.

* `-write-cvcs` has been renamed to `-write-core-solver-queries`
* `LogType::STP` has been renamed to `LogType::CORE_SOLVER_LANG`
* `Interpreter::getConstraintLog()` and `Executor::getConstraintLog()`
  now have a `fileExtension` parameter which returns the file extension
  for constraint language requested.
* The `Solver::getConstraintLog()` and `SolverImpl::getConstraintLog()`
  methods (and all their descendants) now have a `fileExtension`
  parameter which will be set (if requested by the client) to the
  file extension for the core solver's constraint language.
delcypher pushed a commit to delcypher/klee that referenced this issue Mar 24, 2017
There are numerous changes here which removes the assumption that
STP is the core solver.

* `-write-cvcs` has been renamed to `-write-core-solver-queries`
* `LogType::STP` has been renamed to `LogType::CORE_SOLVER_LANG`
* `Interpreter::getConstraintLog()` and `Executor::getConstraintLog()`
  now have a `fileExtension` parameter which returns the file extension
  for constraint language requested.
* The `Solver::getConstraintLog()` and `SolverImpl::getConstraintLog()`
  methods (and all their descendants) now have a `fileExtension`
  parameter which will be set (if requested by the client) to the
  file extension for the core solver's constraint language.
@ccadar
Copy link
Contributor

ccadar commented May 30, 2019

This discussion was moved to #512 , closing.

@ccadar ccadar closed this as completed May 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants