Hyper Gobra #802
Hyper Gobra #802
Conversation
…argument, some incorrect handling of imported adts, conversion issues with ghost data types, name space conflicts with adt types. I changed the representation of adt types, which I still need to double check.
| @@ -68,7 +68,8 @@ object ConfigDefaults { | |||
| val DefaultZ3APIMode: Boolean = false | |||
| val DefaultDisableNL: Boolean = false | |||
| val DefaultMCEMode: MCE.Mode = MCE.Enabled | |||
| val DefaultEnableLazyImports: Boolean = false | |||
| val DefaultHyperMode: Hyper.Mode = Hyper.Enabled | |||
There was a problem hiding this comment.
It would be nice if we could leave this turned on but ensure that if a program does not make use of any SIF specs that we do not perform the product construction.
If this is not easily possible, we have to think about the hyperMode options as "off" currently results in turning all SIF specs to true, which is potentially dangerous if you are not aware of this. Imho, the default mode should make sure that non-SIF programs are encoded as today (i.e., without product construction) and either handle SIF programs soundly or report an error. However, having a mode that allows you to turn SIF checks off for a SIF program could be useful for debugging but this requires a warning / error that this is potentially unsound
| package viper.gobra.util | ||
|
|
||
| import javax.sound.sampled.{AudioFormat, AudioSystem} |
| /** Set this to only transform methods that contain relational assertions somewhere in their spec or body. | ||
| * May lead to invalid programs when such a method calls another methods that does contain such specs. | ||
| */ | ||
| var onlyTransformMethodsWithRelationalSpecs: Boolean = false |
There was a problem hiding this comment.
@ArquintL I guess setting this to true should allow us to keep the default for SIF. I will change it once I start working on this pR
There was a problem hiding this comment.
That's not sufficient. Instead of checking which methods have relational spec and which do not, a first attempt would be to decide this for the entire input program. To keep this on a per-method level, we would first need to address the problem mentioned in the comment above namely that a non-SIF method calling a SIF method (or vice-versa) fails as the number of parameters / arguments does not match.
A similar issue occurs if we would mix methods encoded with optimized SIF encoding (enforcing low control flow) and the more complete SIF encoding as the latter one uses additional parameters (namely the activation variables) and also uses a different ordering for the parameters belonging to the 2nd execution (which is just an implementation detail)
|
The current version, together with the changes from #818 which have been merged in scion leads to an exception on this file: package bugs
// Bug 5.
// Trying to verify this file yields the following error message:
//
// Precondition of call test1(ub) might not hold.
// Permission to ub[0] might not suffice.
//
// The reason can be seen in the generated Viper file: The `_termination_proof`
// method for `test0` replaces the permission amount (`write`) with `wildcard`.
// Note: In order for this bug to occur, `test1` needs to return a struct
// (at least not some primitive type), and the functions must be `pure` (and
// thus also annotated with `decreases`).
//
// This problem first occurred while trying to verify `pkg\slayers\path\epic`.
type Struct struct {}
requires acc(&ub[0])
decreases
pure func test1(ub []byte) Struct {
return Struct{}
}
requires acc(&ub[0])
decreases
pure func test0(ub []byte) bool {
return Struct{} == test1(ub)
}Reported by @henriman |
Felix's implementation of the technique for checking SIF based on this paper