I am not able to distinguish between various precondition and post-condition in ACSL. As I know that requires, terminates and assume comes in precondition and ensures and assigns in post-condition. But in which set rest like decrease etc are??
Can any body is able to help me in figuring out??
thanks in advance
This is a trick question. Basically, decreases would serve as a pre-condition of a recursive call: if you have a function f with decreases x;, if it happens to make a call to itself, you have to prove that x<\at(x,Pre) at this call site. Additionally, you have a pre-condition that x>=0 when you call f (recursive call or not).
Regarding other clauses (based on their order of apperance in ACSL 1.7:
complete and disjoint clause are basically a logical property of the assumes clause of the contract, they do not imply anything for the implementation, but act as a sanity check of the specification itself.
allocates and frees are post-conditions (like for assigns but regarding dynamic allocation)
exits (and returns, breaks and continues) are post-conditions (they are evaluated when we exit the function -or the statement).
dependencies (\from) are post-conditions (like assigns).
decrease clause of ACSL is basically used for recursive function calls.
if you have specified decrease clause with a pointer variable x like: decrease *x;
then what it means is, every time when control enters the function related to this decrease clause, it checks whether the value pointed to by the pointer x is 1 less as compared to the value pointed to by x during the pre-state of the function. For the very first time when the function is called, pre-condition checked is: (*x) >= 0 as the function is in its pre-state so there is no pre-state value to compare to.
Related
I want to do an LLVM compiler for a very old language, PL/M. This has some peculiar features, not least of which is having nested functions with the ability to jump out of an enclosing function. In pseudocode:
toplevel() {
nested() {
if (something)
goto label;
}
nested();
label:
print("finished!");
}
The constraints here are:
you can only jump into the top-level function, luckily
the stack does get unwound (the language does not support destructors, so this is easy)
you do not have to have executed the statement at label before jumping (so the naive setjmp/longjmp method doesn't work).
code at label can be executed normally, i.e. it's not like catch
LLVM has a number of non-local jump mechanisms, such as the exception handling system, but I've never used that. Can this be implemented using LLVM exceptions, or are they not suitable for this? Is there an easier way?
If you want the stack to get unwound, you'll likely want it to be in a separate function, at least a separate LLVM IR function. (The only real exception is if your language does not have a construct like C's "alloca()" and you don't allow calling a nested function by address in which case you could inline it.)
That part of the problem you mentioned, jumping out of an enclosing function, is best handled by having some way for the callee to communicate "how it exited" to the caller, and the caller having a "switch()" on that value. You could stick it in the return value (if it already returns a value, make it a struct of both values), you could add a pointer parameter that it writes to, you could add it a thread-local global variable and fill that in before calling longjmp, or you could use exceptions.
Exceptions, they're complex (I can't describe how to make them work offhand but the docs are here: https://llvm.org/docs/ExceptionHandling.html ) and slow when the exception path is taken, and really intended for exceptional situations, not for normal code. Setjmp/longjmp does the same thing as exceptions except simpler to use and without the performance trade-off when executed, but unfortunately there are miscompiles in LLVM which you need will be the one to fix if you start using them in earnest (see the postscript at the end of the answer).
Those two options cover the ways you can do it without changing the function signature, which may be necessary if your language allows the address to be taken then called later.
If you do need to take the address of nested, then LLVM supports trampolines. See https://llvm.org/docs/LangRef.html#trampoline-intrinsics . Trampolines solve the problem of accessing the local variables of the calling function from the callee, even when the function is called by address.
PS. LLVM miscompiles setjmp/longjmp today. The current model is that a call to setjmp may return twice, and only functions with the returns_twice attribute may return twice. Note that this doesn't affect the whole call stack, only the direct caller of a function that returns twice has to deal with the twice-returning call-- just because function F calls setjmp does not mean that F itself can return twice. So far, so good.
The problem is that in a function with a setjmp, all function calls may themselves call longjmp. I'd say "unless proven otherwise" as with all things in optimizers, but there is no attribute in LLVM doesnotlongjmp or any code within LLVM that attempts to answer the question of whether a function could call longjmp. Adding that would be a good optimization, but it's a separate issue from the miscompile.
If you have code like this pseudo-code:
%entry block:
allocate val
val <- 0
setjmpret <- call setjmp
br i1 setjmpret, %first setjmp return block, %second setjmp return block
%first setjmp return block:
val <- 1;
call foo();
goto after;
%second setjmp return block:
call print(val);
goto after;
%after:
return
The control flow graph shows that is no path from val <- 0 to val <- 1 to print(val). The only path with "print(val)" has "val <- 0" before it therefore constant propagation may turn print(val) into print(0). The problem here is a missing control flow edge from foo() back to the %second setjmp return block. In a function that contains a setjmp, all calls which may call longjmp must have a CFG edge to the second setjmp return block. In LLVM that control flow edge is missing and LLVM miscompiles code because of it.
This problem also manifests in the backend. The first time I heard of this problem it was in the context of the backend losing track of the placement of variables on the stack, and this issue was the underlying root cause.
For the most part setjmp/longjmp seems to work because LLVM isn't usually able to analyze what calling foo() might do and can't perform the optimization. For instance if val was not a fresh allocation but was a pointer, then who's to say that foo() doesn't have access to the same pointer, and then performs "val <- 1" on it? If LLVM can't prove that impossible, that precludes the transform to print(0). Secondly, setjmp/longjmp are just not used often in real code.
Assume having the following setup:
type My is new Integer;
type My_Acc is access My;
procedure Replace(Self : in out My_Acc; New_Int : Integer)
with Pre => New_Int /= Self.all, Post => Self'Old.all /= Self.all;
Note: Code above might not be fully valid, but I hope the concept is understandable.
Now what happens if Unchecked_Deallocation() is used on Self inside Replace
and a new Integer is allocated and set to Self (This should result in Self'Old pointing to a now invalid memory location)?
Does Ada keep kind of a snapshot where Self'Old points to the previous memory location, but before Unchecked_Deallocation() is executed?
If Self'Old would get invalid for use in the Post contract, how could you still access the previous value? Is it possible to create a manual snapshot in the Pre contract that can then be used in Post? Maybe it can be achieved using Ghost_Code?
I want to make everything in Spark, in case that changes something.
Edit: Fixed Self to in out as mentioned by Simon Wright.
Edit: Fixed type of Self to allow null
It may be that the latest versions of SPARK support access types; it used not to, at all.
First, your Not_Null_My_Acc needs to be a subtype of My_Acc, unless you meant it to be a type in its own right.
Second, you can’t deallocate Self inside Replace and allocate a new value; Self is in-mode, & hence not writable.
Third, you can’t apply ’Old to Self, because
warning: attribute "Old" applied to constant has no effect
What you can say is
Post => Self.all'Old /= Self.all;
In ARM 6.1.1(26ff) it says
Each X'Old in a postcondition expression that is enabled denotes a constant that is implicitly declared at the beginning of the subprogram body, entry body, or accept statement.
The implicitly declared entity denoted by each occurrence of X'Old is declared as follows:
...
X'Old : constant S := X;
... in other words, nothing fancy is expected, just a straight copy of (in this case) Self: not Self.all.
So, if your Replace deallocates Self, then Self’Old is a dangling reference, and erroneous.
I suggested previously that changing the postcondition to
Post => Self.all'Old /= Self.all;
would be safe; why wouldn’t that meet your requirements? is there something going on you haven’t told us about?
Note the subtle difference between Self’Old.all and Self.all’Old. The first one takes a copy of Self as it was before the call, which gets dereferenced after the call (by which time it’s pointing into hyperspace), while the second one dereferences the prior Self and copies the integer value it finds there; on return that’s still valid.
I don't even know how to express this question.
A assume there's a pointer to a non evaluated expression. If it's requested (by some strict function that coerces it) then the pointer value is replaced by the value evaluated. Right? Am I wrong?
So I assume every pointer has a flag stating if it has been evaluated or not.
And what if the evaluation is undefined, like the head of an empty list? What is stored in the "pointer"?
I assume there's a pointer to a non evaluated expression. If it's requested (by some strict function that coerces it) then the pointer value is replaced by the value evaluated. Right? Am I wrong?
That's the gist of it.
So I assume every pointer has a flag stating if it has been evaluated or not.
Every pointer points to some structure where you can find that kind of information.
And what if the evaluation is undefined, like the head of an empty list? What is stored in the "pointer"?
The pointer points to an expression whose evaluation throws an exception.
The details are in the following page of the GHC wiki; see in particular "Types of objects": https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/storage/heap-objects
Data constructors, function closures, thunks ("unevaluated expressions") are the main ones.
I want to find some ACSL annotation that can be applied to a function or function pointer to indicate that it has the property of referential transparency. Some way to say "this function will always return the same value when given the same arguments". So far I haven't found any such way. Can anyone point me to a way to express that?
Maybe some way to refer to an arbitrary logic function? If I could name an unknown logic boolean uknown_function(void* a, void* b) = /* this is unkown */; then I could document a function as having a postcondition that it's \result is equal to this arbitrary/unknown logic function?
The larger context is trying to do type-erased comparisons. I want to generally express the concept of "the user has given me void*s to work with and a bool (*)(void const*, void const*) to compare them with, and the user is guaranteeing to me that the function provided really is a strict partial order over whatever those pointers point to." If I had that, then I could start to describe properties of these type-erased objects being sorted, for example.
There is indeed no direct possibility to do that in ACSL: a function contract only specifies what happens during a single call of the function. You could indeed rely on a declared but left undefined logic function, with a reads clause that specifies the part of the C memory state that the function will need to compute its result, e.g.
/*# logic boolean unknown_function{L}(int* a, int* b) reads a[0 .. 1], b[2 .. 3]; */
but if you work with void *, without knowing the size of the underlying objects, this might be tricky to specify: unless the result of unknown_function relies solely on the value of the pointer, and not the content of the pointed object, in which case you don't need that reads trick.
Note in addition that contracts over function pointers are not supported yet, which will probably be an issue for what you intend to do if I understand correctly your last paragraph.
Finally, you might be interested in an upcoming plug-in, RPP, that proposes a way to specify, prove, and use properties relating several calls of one or more C function(s). It is described here and here, and a public release should happen in a not-too-distant future.
I need to if on the value of a Session variable in a reactive computation, and have the computation rerun when the value changes. According to the meteor docs this use case is ideal for Session.equals. So far so good, thus I have in my reactive computation code which calls Session.equals as in:
if (!Session.equals(key, undefined)) {
// now I know 'key' is defined
...
}
The code used to work well but for some reason it stopped doing so. Now (in ver METEOR#1.3.2.4) I'm noticing issues where although the Session value for keychanges, the reactive computation does not get rerun.
In one of my attempts to figure out the cause I've replaced the code with:
if (!!Session.get(key)) {
...
}
Which works - the computation is now getting rerun when expected!
Can anyone tell why would Sesssion.get() work, but not Session.equals()?
Could be relevant: the value of the Session variable changes but it is always 'defined' (e.g. from one non-empty string to another). Would that be sufficient to re-trigger the computation? IOW, maybe Session.equals is 'clever' enough to know the value changed from one defined value to another defined value, thus it establishes that a computation rerun isn't necessary, which causes the issue I'm experiencing?
You have actually answered it yourself.
Session.equals is an optimised version which reruns the computation only if the value has changed. Now as the value doesn't change from 'defined', it won't rerun the computation.