Skip to content

Simplification of nested pointer arithmetic: do not assume same type #6541

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 2 commits into from
Mar 22, 2022
Merged

Simplification of nested pointer arithmetic: do not assume same type #6541

merged 2 commits into from
Mar 22, 2022

Conversation

tautschnig
Copy link
Collaborator

Please review commit-by-commit: the first commit is a refactoring only.

  • Each commit message has a non-empty body, explaining why the change was made.
  • n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • n/a 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).
  • n/a My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

@tautschnig tautschnig mentioned this pull request Dec 22, 2021
Closed
@codecov
Copy link

codecov bot commented Dec 22, 2021 •
edited
Loading

Codecov Report

Merging #6541 (b4c2ff1) into develop (afc53d8) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff            @@
##           develop    #6541   +/-   ##
========================================
  Coverage    76.73%   76.73%           
========================================
  Files         1579     1579           
  Lines       181999   182005    +6     
========================================
+ Hits        139652   139658    +6     
  Misses       42347    42347
Impacted Files Coverage Δ
src/util/simplify_expr_int.cpp 85.18% <100.00%> (+0.09%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3f175c9...b4c2ff1. Read the comment docs.

@kroening
Copy link
Member

Does it make sense to tighten the typing rules for pointer arithmetic, and then to change the front-end?
The standard is vague on these, we would need to invent our own.

@tautschnig tautschnig self-assigned this Jan 22, 2022
@tautschnig
Copy link
Collaborator Author

Does it make sense to tighten the typing rules for pointer arithmetic, and then to change the front-end? The standard is vague on these, we would need to invent our own.

I have now extended an existing test: the C front-end already does ensure consistent typing, so I don't think we have an issue in the front-end to resolve. No other place, however, is strict about the types in pointer arithmetic. Perhaps we should be? I don't know.

@tautschnig tautschnig assigned kroening and unassigned tautschnig Jan 22, 2022
@kroening
Copy link
Member

I'd be in favour of tightening the typing; this makes every bit of code that 'reads' a lot easier. There will be more of that than code that 'writes', and that would not get much more difficult.

@tautschnig
Simplification of nested pointer arithmetic: improve readability
7214340 
Use temporaries to ensure const-access where possible and name
subexpressions. This helps navigate the various uses of opX() in this
code.

No change in behaviour is expected. This code is covered by at least 33
of the regression/cbmc/ tests as well as several other regression tests.
@tautschnig
Simplification of nested pointer arithmetic: do not assume same type
b4c2ff1 
Pointer arithmetic is permitted with both signed and unsigned numeric
operands. Nested expressions could possibly mix this when the front-end
does not strictly use the same type for pointer arithmetic as for index
types. Observed in model-checking/kani#708.

Introducing type casts (as needed) exposed a further issue in this code:
it previously did not make sure that it was really the numeric operands
that ended up being grouped together. This became apparent on test
Pointer_Arithmetic15, which specifically constructs such expressions.
@tautschnig tautschnig mentioned this pull request Mar 15, 2022
Closed
@tautschnig
Copy link
Collaborator Author

I'd be in favour of tightening the typing; this makes every bit of code that 'reads' a lot easier. There will be more of that than code that 'writes', and that would not get much more difficult.

@kroening As now being discussed in #6731 making changes in Kani could well be the way to go. That said, however, this PR also fixes other issues in the offending simplifier code as indicated in the commit message, so perhaps merging these changes is a right first step?

@kroening kroening merged commit 724467c into diffblue:develop Mar 22, 2022
@tautschnig tautschnig deleted the fix-rmc-708 branch March 22, 2022 15:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@kroening kroening kroening approved these changes

@peterschrammel peterschrammel Awaiting requested review from peterschrammel peterschrammel is a code owner

Assignees

@kroening kroening

Labels
bugfix
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@tautschnig @kroening