Draft: Add definition taclets for binaryAnd
, binaryOr
, and binaryXOr
#3174
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Until now, KeY could only evaluate the functions
binaryAnd
,binaryOr
, andbinaryXOr
for literal values or in cases where a special case taclet exists(see file "binaryLemmas.key"). For general reasoning, this is insufficient.
This pull request adds new definition taclets for these functions using a new
helper function
bitAt
to extract individual bits from unbounded JavaDL ints.Overview of the taclets added:
bitAt
binaryAndDef
,binaryAndIntDef
,binaryAndLongDef
binaryOrDef
,binaryOrIntDef
,binaryOrLongDef
binaryXOrDef
,binaryXOrIntDef
,binaryXOrLongDef
Using the
bitAt
function, we definebinaryAnd
,binaryOr
, andbinaryXOr
mathematically as bounded sums over all positional values of the result,
depending on the results of the bit operations on the input parameters.
We include three variants of each function definition: One general one where
the user must specify the maximum sign bit index of the two parameters; one for
Java
int
parameters (sign bit index 31); and one for Javalong
parameters(sign-bit index 63). Each taclet opens another proof branch in
which it must be proven that the parameters of the function lie within the
valid range dictated by the sign bit index (e.g.
inRangeInt(left) &
inRangeInt(right)for the Java
int` versions).Discussion Points
binaryOrDef
) force the user to specify the index of the sign bit. The disadvantage of this approach is that these taclets are not useful for proving properties of the bitwise functions which are independent of bit width, e.g.,\forall int a; \forall int b; (binaryOr(a, b) = binaryOr(b, a))
.binaryX
functions, but instead defined theXJint
/XJlong
functions. At the moment, these latter functions are simply intermediate functions which are translated intobinaryX
. It seems that thebinaryX
functions are supposed to be treated as fundamental "mathematical" bitwise functions, although they assume two's complement representation which is not mathematically based. TheXJint
/XJlong
functions clearly encode Java integer semantics into the meaning of the function in their name, thus might be the better "abstraction level" at which to define these functions.