Skip to content

Get lhs_object from byte_extract for goto trace #4480

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

Merged

Conversation

peterschrammel
Copy link
Member

Otherwise fields are missing from the XML output, which breaks downstream integration of a commercial CBMC user.

  • Each commit message has a non-empty body, explaining why the change was made.
  • Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
  • Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
  • My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • White-space or formatting changes outside the feature-related changed lines are in commits of their own.

Copy link
Collaborator

@tautschnig tautschnig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great to see this improving - I don't think you'd even need to add a new test, existing tests like regression/cbmc/array_constraints1 also have this problem.

src.id() == ID_byte_extract_little_endian ||
src.id() == ID_byte_extract_big_endian)
{
return get_object_rec(to_byte_extract_expr(src).op());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remind me, do we actually consider the offset? What you propose is consistent with what's done for index and member expressions, but I'm still wondering whether the overall result is meaningful.

Copy link
Member Author

@peterschrammel peterschrammel Apr 3, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it was not considered. The meaningfulness is questionable, but that probably goes beyond this fix.
It might be good to actually specify what these fields are supposed to mean precisely.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's an example to validate:

#include <assert.h>

int main()
{
  int x;
  char *p = (char *)&x + 2;
  *p = 1;
  assert(x == 0);
}

The trace currently includes byte_extract_little_endian(x, 2l, char)=1 (00000001) - which might not be downstream-consumable, but at least is accurate. If after this PR the result is x=1 then there's a problem I'm afraid.

Copy link
Member

@kroening kroening Apr 4, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

goto_trace_steps offer two bits of information:

  1. The thing returned by get_lhs_object() -- that is the object as defined in the C standard, and x is the right answer.
  2. The full_lhs, which is documented to be "after dereferencing". It is supposed to be exactly what gets assigned. The byte_extract expression above is the best answer for that, in my view.

The trace given to the user should show the latter. We may wish to print byte_extract expressions there as a pointer typecast plus dereferencing.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for clarifying! +1 for printing byte_extract as some C expression, which will be important for SV-COMP as well. But I accept that this might be outside the scope of this PR.

<assignment assignment_type="state" base_name="u" display_name="test::u" hidden="false" identifier="test::u" mode="C" step_nr="\d+" thread="0">
<location file=".*" function="test" line="\d+" working-directory=".*"/>
<type>union myunion</type>
<full_lhs>byte_extract_little_endian\(u, 0l, .*int.*\)</full_lhs>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also add --little-endian to the command line to make sure this test is portable.

@peterschrammel peterschrammel force-pushed the byte-extract-lhs-object branch 2 times, most recently from 5a2c9a6 to 8d4a15f Compare April 3, 2019 23:30
@peterschrammel peterschrammel force-pushed the byte-extract-lhs-object branch 2 times, most recently from 65de48f to 670219f Compare April 4, 2019 09:08
Otherwise 'identifier' is not displayed in XML output
@peterschrammel peterschrammel force-pushed the byte-extract-lhs-object branch from 670219f to 60b5328 Compare April 4, 2019 10:56
@peterschrammel peterschrammel merged commit 5f68f70 into diffblue:develop Apr 4, 2019
@peterschrammel peterschrammel deleted the byte-extract-lhs-object branch April 4, 2019 12:01
Copy link
Contributor

@allredj allredj left a 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: 60b5328).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/107058275

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 this pull request may close these issues.

5 participants